RFC2162 日本語訳
2162 MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11mail. C. Allocchio. January 1998. (Format: TXT=58553 bytes) (Obsoletes RFC1405) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Allocchio Request for Comments: 2162 I.N.F.N. - Italy Obsoletes: 1405 January 1998 Category: Experimental
Allocchioがコメントのために要求するワーキンググループC.をネットワークでつないでください: 2162 I.N.F.N.--イタリアは以下を時代遅れにします。 1405 1998年1月のカテゴリ: 実験的
MaXIM-11 - Mapping between X.400 / Internet mail
and
Mail-11 mail
MaXIM-11--X.400/インターネット・メールとメール-11メールの間のマッピング
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This document describes a set of mappings which will enable inter working between systems operating the ISO/IEC 10021 - CCITT (now ITU) X.400 Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail or VMSmail) protocol. The specifications are valid both within DECnet Phase IV and DECnet/OSI addressing and routing scheme.
このドキュメントはISO/IEC10021を経営するシステムの間の間の運用を可能にする1セットのマッピングについて説明します--Message Handling Systems、およびメール-11(また、DECnetメールかVMSmailとして、知られている)プロトコルを走らせるシステムの上のCCITT(現在、ITU)X.400 Recommendations。 仕様はDECnet Phase IV、DECnet/OSIアドレシング、およびルーティング計画の中で有効です。
The complete scenario of X.400 / MIME / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations.
また、X.400/MIME/メール-11の完全なシナリオは考えられます、複数のゲートウェイ翻訳に起こる可能な複雑なケースをカバーするために。
This document covers mainly the X.400 O/R address to/from Mail-11 address mapping and the RFC822 to/from Mail-11 ones; other mappings are based on MIXER specifications. Bodypart mappings are not specified in this document: MIXER and MIME-MHS specifications can be applied to map bodyparts between X.400, MIME and Mail-11, too. In fact MIME encoding can be used without modifications within Mail-11 text bodyparts.
このドキュメントはメール-11のものからのメール-11アドレス・マッピングとRFC822から/までの/にX.400O/Rアドレスを主にカバーしています。 他のマッピングはMIXER仕様に基づいています。 Bodypartマッピングは本書では指定されません: X.400とMIMEとメール-11の間でもbodypartsを写像するためにMIXERとMIME-MHS仕様を適用できます。 事実上、メール-11テキストbodypartsの中で変更なしでMIMEコード化を使用できます。
This document obsoletes RFC 1405, which was a combined effort of TERENA Working Group on Messaging, and the IETF X.400 Ops Working Group. This update was prepared by IETF MIXER working group.
このドキュメントはRFC1405を時代遅れにします。(RFCはMessaging、およびIETF X.400 Ops作業部会におけるTERENA作業部会の協力でした)。 このアップデートはIETF MIXERワーキンググループによって準備されました。
Allocchio Experimental [Page 1] RFC 2162 MaXIM-11 January 1998
Allocchio[1ページ]実験的なRFC2162格言1998年1月11日
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 ISO/IEC 10021 - CCITT 1984, 1988 and 1992 X.400 Series Recommendations covering the Message Oriented Text Interchange Service (MOTIS). This document covers the Inter Personal Messaging System (IPMS) only.
"X.400"がISO/IEC10021に関連して、規格はすぐこのドキュメントに参照されました--メッセージの指向のテキスト置き換えサービス(MOTIS)をカバーするCCITT1984、1988と1992のX.400シリーズ推薦。 このドキュメントは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 among systems implementing the DECnet Phase IV and DECnet/OSI (CLNS) networking protocols.
また、DECnetメールとして知られていて、VMSmailとしてしばしば不適切に参照されたメール-11は、DECnet Phase IVとDECnet/オウシ(CLNS)ネットワーク・プロトコルを実行しながらシステムの中でリアルタイムのテキスト・メッセージングシステムを証明するためにDEC(12月)によって実行された固有のプロトコルです。
1.3. RFC822 / MIME
1.3. RFC822/MIME
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. MIME specifications allows transport of non-textual information into RFC822 messages. Their mapping with X.400 is fully described in MIXER and MIME-MHS. In this document we will consider their relations with Mail-11, too.
RFC822はDARPAインターネットの中で個人的なメッセージシステムの規格と定義されて、現在多くの異なったメッセージ転送プロトコルの上で拡散します、SMTPのように、UUCP、Bitnet、JNT Grey Book、CSnet。 MIME仕様は非文字情報の輸送をRFC822メッセージに許容します。 X.400があるそれらのマッピングはMIXERとMIME-MHSで完全に説明されます。 本書では私たちはメール-11とも彼らの関係を考えるつもりです。
1.4. The user community
1.4. ユーザーコミュニティ
The community using MIME or 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 and with MIME based systems. Among these large DECnet based networks we can include the High Energy Physics network (HEPnet) and the Space Physics Analysis Network (SPAN).
あります、そして、MIMEかX.400メッセージシステムを使用する共同体は現在、全世界で発展していますが、それでも、容易にベースのシステムX.400のベースのMessage Handling SystemsとMIME Amongと私たちが伝えることができるこれらの大きいDECnetベースのネットワークを伝えても構わないと思っているシステムを通信させながら基づくメール-11を使用する多くの非常に大きい共同体がHigh Energy Physicsネットワーク(HEPnet)とSpace Physics Analysis Network(SPAN)を含めます。
Many other local communities actively use internally Mail-11 mailing protocols. As any other "non standard" mail protocol, using non standard mapping techniques between Mail-11 and standard mail systems can produce unpredictable results.
他の多くの地方の共同体が、プロトコルを郵送しながら、活発に内部的にメール-11を使用します。 いかなる他の「非標準」のメールプロトコルとしても、メール-11と郵便システムの間の非標準のマッピングのテクニックを使用すると、予測できない結果を生むことができます。
For these reasons a set of rules covering conversion between Mail-11 and X.400 or MIME is described in this document.
これらの理由で、メール-11とX.400かMIMEの間の変換をカバーする1セットの規則が本書では説明されます。
Allocchio Experimental [Page 2] RFC 2162 MaXIM-11 January 1998
Allocchio[2ページ]実験的なRFC2162格言1998年1月11日
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 and RFC822/MIME specifications support a complex and large amount of service elements. Considering the case where a message is relayed between two X.400 MHS or MIME Message Transport System (MTS) via a Mail-11 messaging system this could result in a nearly complete loss of information.
メール-11プロトコルはInterパーソナルMessage(IPM)を構成する非常に制限されたセットの要素を提供しますが、X.400とRFC822/MIME仕様は複雑で多量のサービス要素を支えます。 これは情報のほとんど完全な損失をもたらして、メッセージが2X.400 MHSかMIME Message Transport System(MTS)の間でメール-11メッセージシステムでリレーされるケースを考えるかもしれません。
To minimise the inconvenience, any of the X.400 or MIME service elements which do not map directly into Mail-11 equivalent ones accordingly to this specification, will be included into Mail-11 text body parts as an additional RFC822-like header; this additional header will be inserted between the Mail-11 P2 headers (From:, To:, CC:, Subj:) and the other Mail-11 bodyparts. In particular, X.400 elements will also be at first converted into textual representation before insertion.
不便か、直接それに従って、メール-11の同等なものにどんな地図も翻訳しないX.400かMIMEサービス要素のどれかをこの仕様に最小とならせるように、追加RFC822のようなヘッダーとしてメール-11のテキスト身体の部分に含められるでしょう。 この追加ヘッダーはメール-11個のP2ヘッダー(From:、To:、CC:、Subj:)と他のメール-11bodypartsの間に挿入されるでしょう。 また、特に、X.400要素は挿入の前に初めに、原文の表現に変換されるでしょう。
An example, where a multimedia message has been encoded into mail-11 after having crossed also a MIME-MHS (MIXER conformant) gateway:
例:そこでは、MIME-MHS(MIXER conformant)ゲートウェイを越えた後にも、マルチメディアメッセージがメール-11にコード化されました。
From: smtp%"Admin@SURFnet.nl" "Erik" 18-OCT-1994 13:55:00.49
To: ALLOCCHIO
CC: smtp%"netman@MailFLOW.dante.net"
Subj: enjoy this nice picture!
From: smtp%" Admin@SURFnet.nl "「エリック」18 10月の1994 13: 55:00.49To: ALLOCCHIO CC: smtp%" netman@MailFLOW.dante.net "Subj: この良い絵を楽しんでください!
X400-Originator: root@sun3.SURFnet.nl
X400-Recipients: Allocchio@elettra.ts.it, netman@MailFLOW.dante.net
Sender: Erik Newmann <root@SURFnet.nl>
Organisation: SURFnet bv
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaa0"
Content-ID: <21223.78342785@SURFnet.nl>
X400-創始者: root@sun3.SURFnet.nl X400-受取人: Allocchio@elettra.ts.it 、netman@MailFLOW.dante.net送付者: エリック Newmann <root@SURFnet.nl 、gt;、機構: SURFnet bv Mime-バージョン: 1.0コンテントタイプ: 複合か混ぜられる。 「境界=」----- =_aaaaaa0"コンテントID: <21223.78342785@SURFnet.nl>。
------- =_aaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <21223.78342785@SURFnet.nl>
------- =_aaaaaa0コンテントタイプ: テキスト/平野。 charsetが等しい、「私たち、-、ASCII、」 コンテントID: <21223.78342785@SURFnet.nl>。
look... you never saw this one!!
I just include the picture in the next bodypart
and I hope you get it fine.
見てください… あなたはこれを決して見ませんでした! 私はただ次のbodypartの絵を入れます、そして、あなたがすばらしくなることを願っています。
Allocchio Experimental [Page 3] RFC 2162 MaXIM-11 January 1998
Allocchio[3ページ]実験的なRFC2162格言1998年1月11日
regards,
あいさつ
Erik (continues...)
エリック(続けています)
------- =_aaaaaa0 (continued...)
Content-Type: image/gif
Content-ID: <21223.78342785@SURFnet.nl>
Content-Description: a nice snapshot!
Content-Transfer-Encoding: base64
------- =_aaaaaa0(続けられています) コンテントタイプ: イメージ/gifコンテントID: <の21223.78342785@SURFnet.nlの>の満足している記述: 良いスナップ! 満足している転送コード化: base64
RAV8372FAASD83D721NSHDHD3ASDFJKHWEHKJHCBASDFA829CA8SDB29B132RBAKDFA
9KSJ2KJAA0SDFNAL20DDKFALJ20AJDLFB239B9SC9B29BA9BDFADSDF03998ASDFASD
RAV8372FAASD83D721NSHDHD3ASDFJKHWEHKJHCBASDFA829CA8SDB29B132RBAKDFA9KSJ2KJAA0SDFNAL20DDKFALJ20AJDLFB239B9SC9B29BA9BDFADSDF03998ASDFASD
------- =_aaaaaa0
------- =_aaaaaa0
We need, in fact, to consider also the case when a message originates from a network implementing RFC822/MIME protocols and is relayed via Mail-11 to an X.400 MHS, or vice versa.
事実上、私たちは、また、メッセージがRFC822/MIMEプロトコルを実行するネットワークから発して、X.400 MHSへのメール-11でリレーされるか、逆もまた同様ですときにケースを考える必要があります。
Whenever any X.400 element not covered in this specification needs to be converted into textual representation (to be included into a Mail-11 RFC822-like header or text bodypart) we will apply the rules specified in MIXER (X.400 to RFC822/MIME sections).
この仕様でカバーされなかったどんなX.400要素も、原文の表現(メール-11のRFC822のようなヘッダーかテキストbodypartに含められる)に変換される必要があるときはいつも、私たちはMIXER(RFC822/MIME部へのX.400)で指定された規則を適用するつもりです。
Vice versa, MIXER specification (RFC822/MIME to X.400 sections) also gives the correct rules to convert from textual representations contained into Mail-11 RFC822-like header or bodyparts into X.400 elements.
逆もまた同様です、また、MIXER仕様(X.400部へのRFC822/MIME)はメール-11のRFC822のようなヘッダーかbodypartsに含まれた原文の表現からX.400要素に変えるために正しい規則を与えます。
On the other hand, RFC822/MIME headers not covered by this specification are included 'as they are' into Mail-11 RFC822-like header and bodyparts. The way back from Mail-11 to RFC822/MIME structure becomes thus straightforward.
他方では、この仕様で覆われなかったRFC822/MIMEヘッダーは'彼ら'のようにメール-11のRFC822のようなヘッダーとbodypartsに含められています。 メール-11〜RFC822/MIME構造への道はその結果、簡単になります。
The above methods assures maximum transparency and minimal or null loss of information also when Mail-11 is involved.
かかわる方法が、メール-11であるのに情報の最大の透明と最小量の、または、ヌルの損失にも保証する上記。
Allocchio Experimental [Page 4] RFC 2162 MaXIM-11 January 1998
Allocchio[4ページ]実験的なRFC2162格言1998年1月11日
2.2. Mail-11 service elements to X.400 service elements.
2.2. X.400へのメール-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-11.From and P1-11.To, and any other Mail-11 element belongs to Mail-11 P2:
すべての封筒(P1)とメール-11のヘッダー(P2)サービス要素が変換でX.400に支えられます。 メール-11P1がP1-11.FromとP1-11.Toによって唯一構成されることに注意してください。そうすれば、いかなる他のメール-11要素もメール-11P2に属します:
- P1-11.From
maps to P1.Originator
- P1.OriginatorへのP1-11.From地図
- P1-11.To
maps to P1.Primary Recipient
- P1.Primary RecipientへのP1-11.To地図
- P2-11.'From:'
usually maps to P2.Originator (see section 2.6)
- P2-11'From:'通常P2.Originatorへの地図(セクション2.6を見ます)
- P2-11.'To:'
maps to P2.Primary Recipient
- P2-11P2.Primary Recipientへの'To:'という地図
- P2-11.'CC:'
maps to P2.Copy Recipient
- P2-11P2.Copy Recipientへの'CC:'という地図
- P2-11.Date
maps to P2.Submission Time Stamp
- P2.Submission Time StampへのP2-11.Date地図
- P2-11.'Subj:'
maps to P2.Subject
- P2-11'首題:'P2.Subjectへの地図
Any eventual RFC822-like text header in Mail-11 body part will be interpreted as specified into MIXER.
メール-11身体の部分のどんな最後のRFC822のようなテキストヘッダーもMIXERに指定されるように解釈されるでしょう。
2.3. X.400 service elements to Mail-11 service elements
2.3. メール-11のサービス要素へのX.400サービス要素
The following X.400 service elements are supported directly into Mail-11 conversion:
以下のX.400サービス要素は直接メール-11変換するのに支えられます:
- P1.Originator
maps to P1-11.'From:'
- P1-11'From:'へのP1.Originator地図
- P1.Primary Recipients
maps to P1-11.'To:'
- P1-11'To:'へのP1.Primary Recipients地図
- P2.Originator
usually maps to P2-11.'From:' (see section 2.6)
- 通常、P2.Originatorは. 'From:'をP2-11に写像します。(セクション2.6を見ます)
- P2.Primary Recipients
maps to P2-11.'To:'
- P2-11'To:'へのP2.Primary Recipients地図
Allocchio Experimental [Page 5] RFC 2162 MaXIM-11 January 1998
Allocchio[5ページ]実験的なRFC2162格言1998年1月11日
- P2.Copy Recipients
maps to P2-11.'CC:'
- P2-11'CC:'へのP2.Copy Recipients地図
- P2.Submission Time Stamp
maps to P2-11.Date
- P2-11.DateへのP2.Submission Time Stamp地図
- P2.Subject
maps to P2-11.'Subj:'
- P2-11'首題へのP2.Subject地図:、'
The following X.400 service element is partially supported into Mail-11 conversion:
以下のX.400サービス要素はメール-11変換に部分的に支えられます:
- P2.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アドレスを含むときの以下の動作を必要なプライバシーに確実にするP2.Blind Copy Recipientは起こります: - 身体の部分を含んでいて、新しいメッセージは作成されます。 - 創始者とBCC受取人アドレスだけを含んでいて、新しい封筒は新しいメッセージに追加されます。 - 注意はメッセージがBCCであったという事実に関してBCC受取人に知らせるメッセージに追加されます。 - 別々に新しいメッセージを送ります。 - 注意は何人かのBCC受取人もいたという事実に関してTOに渡されたメッセージと彼らを知らせるCC受取人に追加されます。
Any other X.400 service element support is done accordingly to MIXER including the mapped element into the RFC822-like header into Mail-11 body part.
それに従って、メール-11身体の部分へのRFC822のようなヘッダーに写像している要素を含むMIXERにいかなる他のX.400サービス要素サポートもします。
2.4. Mail-11 service elements to RFC822/MIME service elements.
2.4. RFC822/MIMEへのメール-11のサービス要素が要素を調整します。
All envelope (P1) and header (P2) Mail-11 service elements are supported in the conversion to RFC822/MIME:
すべての封筒(P1)とメール-11のヘッダー(P2)サービス要素が変換でRFC822/MIMEに支えられます:
- P1-11.From
maps to 822-MTS.Originator
- 822-MTS.OriginatorへのP1-11.From地図
- P1-11.To
maps to 822-MTS.Primary Recipient
- 822-MTS.Primary RecipientへのP1-11.To地図
- P2-11.'From:'
usually maps to 822.'From:' (see section 2.6)
- P2-11通常、'From:'は'From:'を822に写像します。(セクション2.6を見ます)
- P2-11.'To:'
maps to 822.'To:'
- P2-11 822 'To:'への'To:'という地図
- P2-11.'CC:'
maps to 822.'Cc:'
- P2-11 822 'Cc:'への'CC:'という地図
Allocchio Experimental [Page 6] RFC 2162 MaXIM-11 January 1998
Allocchio[6ページ]実験的なRFC2162格言1998年1月11日
- P2-11.Date
maps to 822.'Date:'
- 822 '日付:'へのP2-11.Date地図
- P2-11.'Subj:'
maps to 822.'Subject:'
- P2-11'首題:'822 'Subject:'への地図
Any eventual RFC822-like text header in Mail-11 body part will be re-inserted into RFC822/MIME message 'as it is'.
メール-11身体の部分のどんな最後のRFC822のようなテキストヘッダーも'それはそうです'によってRFC822/MIMEメッセージに再び差し込まれるでしょう。
2.5. RFC822/MIME service elements to Mail-11 service elements
2.5. メール-11のサービス要素へのRFC822/MIMEサービス要素
The following RFC822 service elements are supported directly into Mail-11 conversion:
以下のRFC822サービス要素は直接メール-11変換するのに支えられます:
- 822-MTS.Originator
maps to P1-11.From
- P1-11.Fromへの822-MTS.Originator地図
- 822-MTS.Primary Recipients
maps to P1-11.To
- P1-11.Toへの822-MTS.Primary Recipients地図
- 822.'From:'
usually maps to P2-11.'From:' (see section 2.5)
- 822. 'From: '通常P2-11への地図'From:'(セクション2.5を見ます)
- 822.'To:'
maps to P2-11.'To:'
- 822. P2-11'To:'への'To:'という地図
- 822.'Cc:'
maps to P2-11.'CC:'
- 822. P2-11'CC:'への'Cc:'という地図
- 822.'Date:'
maps to P2-11.Date
- 822. P2-11.Dateへの'日付:'という地図
- 822.'Subject:'
maps to P2-11.'Subj:'
- 822. 'Subject:は'P2-11'首題に以下を写像します'。
Allocchio Experimental [Page 7] RFC 2162 MaXIM-11 January 1998
Allocchio[7ページ]実験的なRFC2162格言1998年1月11日
The following RFC822 service element is partially supported into Mail-11 conversion:
以下のRFC822サービス要素はメール-11変換に部分的に支えられます:
- 822.'Bcc:'
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.
- 822. メッセージがBCCアドレスを含むときの以下の動作を必要なプライバシーに確実にする'Bcc:'は起こります: - 身体の部分を含んでいて、新しいメッセージは作成されます。 - 創始者とBCC受取人アドレスだけを含んでいて、新しい封筒は新しいメッセージに追加されます。 - 注意はメッセージがBCCであったという事実に関してBCC受取人に知らせるメッセージに追加されます。 - 別々に新しいメッセージを送ります。 - 注意は何人かのBCC受取人もいたという事実に関してTOに渡されたメッセージと彼らを知らせるCC受取人に追加されます。
Any other RFC822/MIME service element support is done simply including the element 'as it is' into the RFC822-like header and into a Mail-11 body part.
いかなる他のRFC822/MIMEサービス要素サポートも'それはある'ので単にRFC822のようなヘッダーの中と、そして、メール-11身体の部分の中に要素を含め終わっています。
2.6. Rules to define the Mail-11 P2-11.'From:' element
2.6. メール-11P2-11'From:'要素を定義する規則
Mail-11 User Agents (usually VMSmail) uses the P2-11.'From:' element as destination in case the REPLY command is issued, ignoring any other specification like 'Sender:' 'Reply-To:' 'Return-Path:' etc. Also a number of automatic responders uses this field only to address their messages.
メール-11人のUserエージェント(通常VMSmail)がP2-11を使用します。REPLYが命令するといけないので、目的地としての'From:'要素を発行します、'送付者:''Reply-To''リターン経路のようにいかなる他の仕様も無視して: 'など 多くの自動応答者もこの分野を使用しますが、彼らのメッセージを記述します。
Is it thus essential to insert into this field the correct information, i.e. the correct address where, according to X.400 or RFC822 rules the REPLY command or any automatically generated message should go.
その結果、それはすなわち、正しいアドレスの正確な情報、X.400に従ったどこまたはRFC822をこの分野に挿入するかが、REPLYコマンドか何か自動的に発生したメッセージが行くべきであると裁決するのが不可欠ですか?
The rules specified in RFC822, section 4.4.4 should be used as a selection criterion to define the content of this field.
RFC822で指定された規則、セクション4.4.4は、この分野の内容を定義するのに選択基準として使用されるべきです。
In particular, in case the P2-11.'From:' element is not generated from the P2.Originator (X.400) or from the 822.'From:' (RFC822), it is essential to preserve into a 'From:' record of the RFC822-like header the original information contained into the P2.Originator or 822.'From:' fields.
P2-11をケースに入れてください。'From: '要素はP2.Originator(X.400)か822から発生しない'というFrom:'(RFC822)ではP2.Originatorか822の'From:'分野に含まれたオリジナルの情報をRFC822のようなヘッダーに関する'From:'記録として保存するのは特に、不可欠です。
Allocchio Experimental [Page 8] RFC 2162 MaXIM-11 January 1998
Allocchio[8ページ]実験的なRFC2162格言1998年1月11日
Vice versa, when converting from Mail-11 into X.400 or RFC822/MIME the information contained into the 'From:' field of the RFC822-like header (if present) will supersede the one contained into the Mail-11 P2-11.'From:'. An example:
逆もまた同様です、メール-11からX.400かRFC822/MIMEに変えるとき、RFC822のようなヘッダーの'From:'分野に含まれて(現在)の情報はP2-11メール-11'From:'に含まれたものに取って代わるでしょう。 例:
From: smtp%"Admin@SURFnet.nl" "Erik" 18-OCT-1994 13:55:00.49
To: ALLOCCHIO
CC: smtp%"netman@MailFLOW.dante.net"
Subj: enjoy this nice picture!
From: smtp%" Admin@SURFnet.nl "「エリック」18 10月の1994 13: 55:00.49To: ALLOCCHIO CC: smtp%" netman@MailFLOW.dante.net "Subj: この良い絵を楽しんでください!
From: Erik Newmann <root@SURFnet.nl>
Reply-To: Admin@SURFnet.nl
Organisation: SURFnet bv
Message-Id: <21235.25442281@SURFnet.nl>
From: エリック Newmann <root@SURFnet.nl 、gt;、Reply-To Admin@SURFnet.nl 機構: SURFnet bv Message-イド: <21235.25442281@SURFnet.nl>。
when converting back into RFC822 the header will be:
RFC822を変換し返すとき、ヘッダーは以下の通りになるでしょう。
From: Erik Newmann <root@SURFnet.nl>
Reply-To: Admin@SURFnet.nl
To: Allocchio@elettra.ts.it
Cc: netman@MailFLOW.dante.net
Subject: enjoy this nice picture!
Organisation: SURFnet bv
Message-Id: <21235.25442281@SURFnet.nl>
From: エリック Newmann <root@SURFnet.nl 、gt;、Reply-To Admin@SURFnet.nl To: Allocchio@elettra.ts.it Cc: netman@MailFLOW.dante.net Subject: この良い絵を楽しんでください! 機構: SURFnet bv Message-イド: <21235.25442281@SURFnet.nl>。
The described method, although violating canonical conversion principles, assures the maximum functionality to the users, and provides consistency in case of multiple conversions for a single message.
説明された方法は、正準な変換原則に違反しますが、最大の機能性をユーザに保証して、複数の変換の場合にただ一つのメッセージに一貫性を提供します。
Chapter 3 - Basic Mappings
第3章--基本のマッピング
The basic mappings indicated in MIXER and its updates should be fully used.
MIXERで示された基本のマッピングとそのアップデートは完全に使用されるべきです。
A special consideration must be used for encoding RFC822 addresses containing quotes '"' into Mail-11. In fact Mail-11 addresses cannot contain that special character, as it is reserved to delimit "quoted strings" themselves, as when using the Mail-11 foreign mail protocol. An example:
引用文を含むRFC822アドレスをコード化するのに特別の配慮を使用しなければならない、'、「'メール-11に'、」 事実上、メール-11のアドレスはその特殊文字を含むことができません、それがいつとして使用している「引用文字列」自体外国メール-11メールプロトコルを区切るかために予約されるとき。 例:
"John Poe"@Mixergw.local.ca.us (RFC822)
「ジョン・ポー」@Mixergw.local.ca.us(RFC822)
cannot be included in a Mail-11 foreign mail protocol address 'as is', due to the quotes in the LHS section. Quotes must thus be encoded. MIXER specifies exactly how to encode quotes and other characters when translating RFC822 addresses into X.400. Mail-11 addresses are not limited to printablestring, as for X.400, but a
LHS部の引用文のためメール-11の外国メールプロトコルアドレスに'そのままで'含むことができません。 その結果、引用文をコード化しなければなりません。 MIXERはちょうどRFC822アドレスをX.400に翻訳するとき、引用文と他のキャラクタをコード化する方法を指定します。 メール-11のアドレスはX.400によってprintablestringしますが、aに制限されません。
Allocchio Experimental [Page 9] RFC 2162 MaXIM-11 January 1998
Allocchio[9ページ]実験的なRFC2162格言1998年1月11日
subset of the MIXER encoding can be used for the quotes character,
and, as a direct consequence, for open and closed round brackets '('
and ')':
そして、引用文のキャラクタに直接の結果としてMIXERコード化の部分集合を使用できます、開いていて閉じている丸括弧のために'('')':
smtp%"(q)John Poe(q)@Mixergw.local.ca.us"
smtp%「(q) ジョンポー(q)@Mixergw.local.ca.us」
Chapter 4 - Addressing - Mail-11 / X.400
第4章--アドレシング--メール-11 / X.400
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ストリングです。
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 RFC1685 and CCITT F.401, Annex B.
他方では、An X.400O/Rアドレスは属性の収集です、Annex B。(とにかく、RFC1685とCCITT F.401で定義されるIA5の原文の表現として属性を提示できます)。
4.3. Mail-11 address components
4.3. メール-11個のアドレス構成要素
Let us start defining the different parts composing a Mail-11 address. Mail-11 addresses syntax is slightly different between Phase IV and DECnet/OSI cases:
メール-11アドレスを構成する異なった部品を定義し始めましょう。 メール-11アドレス構文はPhase IVとDECnet/OSIケースの間でわずかに異なっています:
- Phase IV: we consider a Mail-11 address as composed by 3 parts:
- フェーズIV: 私たちは、3つの部品によって構成されるようにメール-11がアドレスであると考えます:
[route] [node::] local-part
[ルート]、[ノード:、:、]、地方の部分
where 'route' and 'node' are optional and only 'local-part' is compulsory.
どこで、'ルート'と'ノード'が任意、そして、'地方の部分'であるだけであるかは、義務です。
- DECnet/OSI: we consider a Mail-11 address as composed by 3 parts:
- DECnet/OSI: 私たちは、3つの部品によって構成されるようにメール-11がアドレスであると考えます:
[net:] [node-clns::] local-part
[以下を網状にならせます]、[ノード-clns:、:、]、地方の部分
where 'net and 'node-clns' are optional and only 'local-part' is compulsory.
'ネットと'はノードclns任意です、そして、'地方の部分'だけ、が強制的である'ところ
Here comes a formal definition of these elements
これらの要素の公式の定義はここに来ます。
node = *(ALPHA/DIGIT) / *DIGIT / *DIGIT "." *DIGIT
「ノード=*(アルファー/DIGIT)/*DIGIT/*DIGIT」、」 *ケタ
route = *(node "::")
ルート=*「(ノード、」、:、:、」、)
subdomain = *(ALPHA/DIGIT)
サブドメイン=*(アルファー/ケタ)
Allocchio Experimental [Page 10] RFC 2162 MaXIM-11 January 1998
Allocchio[10ページ]実験的なRFC2162格言1998年1月11日
node-clns = *("." subdomain)
ノード-clnsは*と等しいです。(「. 」 サブドメイン、)
net = *(ALPHA/DIGIT)
ネットの=*(アルファー/ケタ)
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 x400-text-address both the ";" notation and the
"/" notation are equivalent and allowed (see examples in different
sect.)
「アドレスのx400テキスト両方でそれに注意してください、」、;、」 そして、「記法、」 /、」 記法は同等で許容されています。(異なったセクトで例を見てください。)
Some examples (Phase IV):
いくつかの例(フェーズIV):
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 "
Allocchio Experimental [Page 11] RFC 2162 MaXIM-11 January 1998
Allocchio[11ページ]実験的なRFC2162格言1998年1月11日
Some examples (DECnet/OSI):
いくつかの例(DECnet/OSI):
net node local-part
-----------------------------------------------------------
USER47
.IT.MYDOM1.MYNODE::BETTY
OMNI:.US.GOV.LB.GOOFY1::MARY34
IN%"M.P.Tracy@Dicdum.cc.edu"
NET1:.SALES.ADM.MVAX93::MRGATE::"MBOX1::MBX34::MYC3::BOB"
.FR.LYON.MIAMI2::George.Rosenthal
.AU.ABXY2W.VS3100::Jnet%"IAB3425@IBAX23L"
MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
INT:.GB.3LABV56.MAINV::IN%"path1!path2!user%dom"
GWX400::gw%"C=xx;ADMD=aaa;PRMD=ppp;S=Lee;"
smtp%"postmast@nodeb.bitnet"
OMNI:.DE.TEST.V1.GWY32::GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee"
ネットのノード地方の一部----------------------------------------------------------- USER47 .IT.MYDOM1.MYNODE:、:ベティ、全、: .US.GOV.lb GOOFY1:、:" M.P.Tracy@Dicdum.cc.edu "NET1: MARY34インチ.SALES.ADM.MVAX93:、:「MRGATE:、:、」MBOX1:、:MBX34:、:MYC3:、:「ボブ」.FR.LYON.MIAMI2:、:George.Rosenthal .AU.ABXY2W. VS3100:、:「Jnet%" IAB3425@IBAX23L "MRGATE:、:、」C=は以下をxxします:A=bbb:、:Pはpppと等しいです:、:INT: 「Sはジョーと等しく」.GB.3LABV56.MAINV:、:「インチ」 path1!path2!ユーザ%dom」GWX400:、:gw%、「C=xx; ADMD=aaa; PRMDはpppと等しいです; Sはリーと等しいです」。 " postmast@nodeb.bitnet "OMNI: smtp%.DE.TEST.V1.GWY32:、:GX409A::「x400%xx/A=aaa/P」 /C==ppp/S=リー」
Note that also in DECnet/OSI there can be Phase IV like node names, the so called "Phase IV compatibility node names", but no 'route' term is allowed in front of them. In case the address consists of a DECnet/OSI 'net' and/or 'node' specification, plus an old Phase IV node address (like the last one in above examples) we consider the old Phese IV node name (GX409A) as 'local-part'.
いわゆる「フェーズIV互換性ノード名」が好きですが、また、あることができるDECnet/OSIではPhase IVがノード名、どんな'ルート'用語も好きでないというメモがそれらの正面に許容されています。 場合では、アドレスは私たちが'地方の部分'として古いPhese IVノード名(GX409A)であると考えるDECnet/OSI'ネット'、そして/または、'ノード'仕様、および古いPhase IVノードアドレス(上記の例における最後のもののような)から成ります。
Chapter 5 - Mapping - Mail-11 / X.400
第5章--マッピング--メール-11 / X.400
5.1. Mapping scheme
5.1. マッピング計画
DECnet phase IV address field is somehow a 'flat land' with some obliged routes to reach some hidden areas. Thus a truly hierarchical mapping scheme using mapping rules as suitable for RFC822 is not the appropriate solution. A fixed set of encoding rules using DDAs support is defined in order to define the mapping.
DECnetフェーズIVアドレス・フィールドはどうにかいくつかの隠された領域に達するいくつかの強いられたルートがある'平坦な土地'です。 したがって、RFC822に適当であるとして配置規則を使用する本当に階層的なマッピング計画は適切な解決策ではありません。 DDAsサポートを使用する固定セットの符号化規則は、マッピングを定義するために定義されます。
DECnet/OSI address field is, on the other hand, hyerarchical, implementing a real domain style organization, resembling very closely the RFC822 domain addresses. However also in DECnet/OSI networks the old Phase IV flat addresing schema remains valid, expecially for the so called 'Phase IV short aliases'. For this reason, and to keep mapping as simple as possible, the same set of fixed rules usind DDAs encoding will be used both for Phase IV and DECnet/OSI addresses.
他方では、DECnet/OSIアドレス・フィールドはhyerarchicalです、本当のドメインスタイル組織を実行して、非常に密接にRFC822ドメインアドレスに類似していて。 しかしながら、DECnet/OSIネットワークではも、古いPhase IV平坦なaddresing図式は有効なままで残っています、いわゆる'フェーズのIVの短い別名'において、expeciallyです。 この理由、できるだけ簡単で、同じセットの固定規則を写像し続けるために、usind DDAsコード化はPhase IVとDECnet/OSIアドレスに使用されるでしょう。
Allocchio Experimental [Page 12] RFC 2162 MaXIM-11 January 1998
Allocchio[12ページ]実験的なRFC2162格言1998年1月11日
Another important aspect of the problem is the coexistence in DECnet phase IV of many disjoint 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. In DECnet/OSI this aspect is more canonically approached, introducing the concept of 'net', a unique name identifying the single internally fully interconnected DECnet network sharing the same DECnet/OSI name space.
問題の別の重要な一面は多くのDECnetフェーズIVにおける共存がネットワーク、同じDECnetアドレス空間、すなわち、一般的なX.400を使用する、そして/または、異なった孤立しているメール-11の島をつなげるために接着剤としてシステム芝居を郵送するRFC822をばらばらにならせるということです。 DECnet/OSIでは、この局面は、より正準に近づかれます、'ネット'(同じDECnet/OSI名前スペースを共有する内部的に完全にインタコネクトされたただ一つのDECnetネットワークを特定するユニークな名前)の概念を紹介して
To identify uniquely each DECnet Phase IV network we will thus extend the concept of DECnet/OSI 'net' also to this case. We define as 'net' in Phase IV a unique ASCII string identifying the DECnet network we are connected to. If the Phase IV network is already migrating and thus interconnected to DECnet/OSI areas, the 'net' identifier already used in the DECnet/OSI areas is automatically extended to the whole DECnet community.
唯一それぞれのDECnet Phase IVネットワークを特定するために、その結果、私たちは本件にもDECnet/OSI'ネット'の概念について敷衍するつもりです。 私たちはPhase IVで私たちが接続されるDECnetネットワークを特定するユニークなASCIIストリングを'ネット'と定義します。 Phase IVネットワークは、既に移動して、DECnet/OSI領域で既に使用された'ネット'の識別子は自動的に全体のDECnet共同体に広げられて、このようにしてDECnet/OSI領域とインタコネクトされます。
If the network still uses Phase IV protocols only, a 'net' identifier must be chosen. In this case the 'net' element will identify the DECnet community being served, but it could also differ from the actual official network name. It is reccommended that the same 'net' identifier will be adopted unmodified when the eventual migration to DECnet/OSI will take place within that DECnet community.
ネットワークがまだPhase IVプロトコルだけを使用しているなら、'ネット'の識別子を選ばなければなりません。 この場合、'ネット'の要素は役立たれているDECnet共同体を特定するでしょうが、また、それは実際の公式のネットワーク名と異なるかもしれません。 DECnet/OSIへの最後の移動がそのDECnet共同体の中で行われるとき、reccommendedされて、そんなに同じ'ネット'の識別子が変更されていなく採用されるということです。
Aliases are allowed for the 'net' identifier. Some well known identifiers and aliases:
別名は'ネット'の識別子のために許容されています。 いくつかのよく知られている識別子と別名:
net = 'OMNI' the High Energy Physics & Space Physics
DECnet network;
ネットは'OMNI'High Energy PhysicsとSpace Physics DECnetネットワークと等しいです。
aliases:
別名:
net = 'HEPnet' alias for 'OMNI'
net = 'SPAN' alias for 'OMNI'
'OMNI'ネットのためのネットの='HEPnet'別名は'OMNI'のために通称'SPAN'と等しいです。
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 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.
また、名前でそれぞれのDECnetネットワークをラベルする必要性は'知的な'ゲートウェイを実行するという要件から来ます、すなわち、直接指定されたDECnetネットワークに接続する性能を理解できるゲートウェイ、O/Rアドレスが異なったゲートウェイに経路を指定しても。 5.3と5.5には問題の、より詳細な議論があります。
Allocchio Experimental [Page 13] RFC 2162 MaXIM-11 January 1998
Allocchio[13ページ]実験的なRFC2162格言1998年1月11日
A registry of 'net' attributes to insure uniqueness of names must be established: this registry is the same one created for migration to DECnet/OSI. A simple table coupling 'net' and the gateway address is also used, in a syntax similar to the 'gate1' and 'gate2' tables used in MIXER. An example:
名前のユニークさを保障する'ネット'の属性の登録を確立しなければなりません: この登録は移動のためにDECnet/OSIに作成された同じ1つです。 また、カップリング'ネット'という単純分類表とゲートウェイアドレスは使用されます、MIXERで使用される'gate1'と'gate2'テーブルと同様の構文で。 例:
OMNI#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
OMNI#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it#
HEPnet#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
HEPnet#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it#
SPAN#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
SPAN#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it#
全#の全#の OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT ESRIN1.PRMD$esa.ADMD$Master400.C#O$$、それ、#HEPnet# OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT #HEPnet#O$ESRIN1.PRMD$esa.ADMD$Master400.C$、それ、#長さ# OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT #長さ#O$ESRIN1.PRMD$esa.ADMD$Master400.C$、それ、#
Ambiguous left entries are allowed. Gateway implementations could simply choose among one of the specified gateways, or try them all in cyclic order to obtain better performances.
左のあいまいなエントリーは許容されています。 ゲートウェイ実現は、指定されたゲートウェイの1つの中で単に選ぶか、または、より良い性能を得る周期的な命令でそれらを皆、試みるかもしれません。
Note that aliases are established using this gate table, too: simply
add equivalent entries into the table, like the 'HEPnet' and 'SPAN'
entries. Aliases, however, must be used only to enable users to use
commonly used names, but any gateway implementing this specification
must generate addresses with official 'net' names, only ('OMNI' for
the above table).
別名がまた、このゲートテーブルを使用することで確立されることに注意してください: 'HEPnet'と'SPAN'エントリーのように単に同等なエントリーをテーブルに加えてください。 しかしながら、別名を使用しなければなりませんが、ユーザが一般的に使用された名前を使用するのを可能にするこの仕様を履行するどんなゲートウェイも公式の'ネット'の名前でアドレスを作らなければなりません、唯一です(上のテーブルのための'OMNI')。
The Mail-11 gateways table, however, just constitutes the list of the the appropriate MIXER address translation) RFC822 world. Any other gateway implementing this specification (and the related ones) should use its local name as first choice for the Mail-11 'net' it can reach, and use the official Mail-11 gateway table to reach only the non connected ones. This list of Mail-11 gateway entries is supposed to contain the list of 'net' tags and their aliases; as this list is usually small, currently we do not take into account distribution mechanisms for this information different from a static table.
しかしながら、メール-11ゲートウェイテーブルがただ適切なMIXERアドレス変換のリストを構成する、) RFC822世界。 この仕様(そして、関連するもの)を履行するいかなる他のゲートウェイも、それが達することができるメール-11'ネット'において最初に特選するとして地方名を使用して、非接続されたものだけに達するのに公式のメール-11ゲートウェイテーブルを使用するはずです。 メール-11のゲートウェイエントリーのこのリストは'ネット'のタグとそれらの別名のリストを含むべきです。 このリストが通常小さいので、現在の私たちは静的なテーブルと異なったこの情報のために分配メカニズムを考慮に入れません。
In order to keep the mapping rules very simple, avoiding the need to analyse Mail-11 addresses to distinguish the 'route', 'node', and Attributes (DDAs) needed to cover the mapping problem.
非常に簡単に配置規則を保つために、'ルート'、'ノード'、およびAttributes(DDAs)を区別するためにメール-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
Allocchio Experimental [Page 14] RFC 2162 MaXIM-11 January 1998
Allocchio[14ページ]実験的なRFC2162格言1998年1月11日
We thus define the Mail-11 Phase IV mapping rule:
その結果、私たちはメール-11Phase IV配置規則を定義します:
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。
Meanwhile we define the mapping rule for Mail-11 DECnet/OSI:
その間、私たちはメール-11DECnet/OSIのために配置規則を定義します:
net:node-clns::localpart
ネット: ノード-clns:、:localpart
maps into
地図
C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
DD.Mail-11=node-clns::localpart;
Cはxxと等しいです。 ADMD=yyy。 PRMDはグーグーグーと等しいです。 O=ooo。 OU=uuu。 DD.Dnetはネットと等しいです。 DD.Mail-11=は以下をノードでclnsします:localpart。
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., OMNI, HEPnet, SPAN,...)
xxは変換uuu=Orgを実行するゲートウェイの変換ooo=機構を実行するゲートウェイの変換グーグーグー=Prmdを実行するゲートウェイの変換yyy=Admdを実行するゲートウェイの国名略号と等しいです。 DECnetネットワークの変換ネットの=名を実行するゲートウェイのユニット(例えば、全、HEPnet、長さ)
('zzz','ooo','uuu' being used or dropped appropriately in order to
identify uniquely within the X.400 MHS the gateway performing the
conversion).
('グーグーグー'、'ooo''uuu'が変換を実行しながらX.400 MHSの中で唯一ゲートウェイを特定するために適切に使用されるか、または落とされて。)
The following defaults also apply:
また、以下のデフォルトは適用されます:
if 'node' (or 'node-clns') is missing and we are mapping the Mail-11 originator (From) then 'node' (or 'node-clns') defaults to the DECnet node name of the gateway (gwnode);
'ノード'(または、'ノード-clns')がなくなって、私たちがメール-11創始者(From)を写像しているなら、'ノード'(または、'ノード-clns')はゲートウェイ(gwnode)のDECnetノード名をデフォルトとします。
if 'node' (or 'node-clns') is missing and we are mapping the Mail-11 recipient (To, Cc) then 'node' (or 'node-clns') defaults to the DECnet node name of the 'From' address.
'ノード'(または、'ノード-clns')がなくなって、私たちがメール-11受取人を写像している、(Cc) そして、'ノード'(または、'ノード-clns')は'From'アドレスのDECnetノード名をデフォルトとします。
if '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.
'ネット'がなくなるなら、ゲートウェイによって局所的に定義された値をデフォルトとします: ゲートウェイが1つのDECnetネットワークだけに接続されると、'ネット'はこのユニークなネットワークの名前になるでしょう。 ゲートウェイが1つ以上のDECnetネットワークに接続されると、ゲートウェイは'最初に、選択'DECnetネットワークを設立するでしょう、そして、'ネット'はこの値をデフォルトとするでしょう。
Allocchio Experimental [Page 15] RFC 2162 MaXIM-11 January 1998
Allocchio[15ページ]実験的なRFC2162格言1998年1月11日
The 'node' syntax (DECnet/OSI or Phase IV) depends on the DECnet protocol implemented and on the value of a system parameter (usually the MAIL$SYSTEM_FLAGS one) on the gateway host.
'ノード'構文(DECnet/OSIかPhase IV)が実行されてシステム・パラメータの値のDECnetプロトコルによる、(通常メール、$、SYSTEM_FLAGS1) ゲートウェイホストの上で。
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 'OMNI';
- the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC'
alias 'X4TDEC' in Phase IV;
- 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ネットワーク名(ネットの)は'OMNI'です。 - ゲートウェイ(gwnode)のDECnetノード名はPhase IVの'.IT.DM.X4TDEC'別名'X4TDEC'です。 - ゲートウェイのCountry Codeは'IT'です、そして、ADMDは'garr'(これらの2つの分野がX.400 MHSの中で唯一ゲートウェイを特定するために十分である)です。
USER47
C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=.IT.DM.X4TDEC::USER47;
USER47Cはそれと等しいです。 ADMD=garr。 DD.Dnetが等しい、全、。 DD.Mail-11=.IT.DM.X4TDEC:、:USER47。
MYNODE::BETTY
C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=MYNODE::BETTY;
MYNODE:、:ベティCはそれと等しいです。 ADMD=garr。 DD.Dnetが等しい、全、。 DD.Mail-11=MYNODE:、:ベティ。
BOSTON::GOOFY1::MARY34
C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=BOSTON::GOOFY1::MARY34;
ボストン:、:GOOFY1:、:MARY34Cはそれと等しいです。 ADMD=garr。 DD.Dnetが等しい、全、。 DD.Mail-11はボストンと等しいです:、:GOOFY1:、:MARY34。
.DE.UNI-BN.PHYS.NODE18::MARY34
C=it; ADMD=garr; DD.Dnet=OMNI;
DD.Mail-11=.DE.UNI-BN.PHYS.NODE18::MARY34;
.DE.UNI-BN.PHYS.NODE18:、:MARY34Cはそれと等しいです。 ADMD=garr。 DD.Dnetが等しい、全、。 DD.Mail-11=.DE.UNI-BN.PHYS.NODE18:、:MARY34。
UCLA13::MVAX93::MRGATE::"MBOX1::MBX34:MYC3::BOB"
C=it; ADMD=garr; DD.Dnet=OMNI;
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)
ENET:.US.CENTRAL.MIAMI2::George.Rosenthal
C=it; ADMD=garr; DD.Dnet=ENET;
DD.Mail-11=.US.CENTRAL.MIAMI2::George.Rosenthal;
ENET: .US.CENTRAL.MIAMI2:、:George.Rosenthal Cはそれと等しいです。 ADMD=garr。 DD.Dnet=ENET。 DD.Mail-11=.US.CENTRAL.MIAMI2:、:George.Rosenthal。
MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
C=it; ADMD=garr; DD.Dnet=OMNI;
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)
Allocchio Experimental [Page 16] RFC 2162 MaXIM-11 January 1998
Allocchio[16ページ]実験的なRFC2162格言1998年1月11日
MAINVX::In%"path1!path2!user%dom"
C=it; ADMD=garr; DD.Dnet=OMNI;
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
and for DECnet/OSI addresses
そして、DECnet/OSIアドレスのために
C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
DD.Mail-11=node-clns::localpart;
Cはxxと等しいです。 ADMD=yyy。 PRMDはグーグーグーと等しいです。 O=ooo。 OU=uuu。 DD.Dnetはネットと等しいです。 DD.Mail-11=は以下をノードでclnsします:localpart。
maps into
地図
net:node-clns::localpart
ネット: ノード-clns:、: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"。
Allocchio Experimental [Page 17] RFC 2162 MaXIM-11 January 1998
Allocchio[17ページ]実験的なRFC2162格言1998年1月11日
Again for DECnet/OSI addresses:
再びDECnet/OSIアドレスのために:
C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net;
DD.Mail-11=node-clns::localpart;
Cはxxと等しいです。 ADMD=yyy。 PRMD=www。 DD.Dnetはネットと等しいです。 DD.Mail-11=は以下をノードでclnsします:localpart。
maps into
地図
gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net;
DD.Mail-11=node-clns::localpart;"
gwnode:、:「C=xx; ADMD=yyy; PRMD=www; DD.Dnet=は網で覆う」gw%。 DD.Mail-11=は以下をノードでclnsします:"localpart"。
5.3.1. Examples
5.3.1. 例
Let us suppose that:
以下のことと思いましょう。
- the DECnet network name (net) is 'OMNI';
- the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC';
alias 'X4TDEC' in Phase IV;
- the Country Code of the gateway is 'IT' and its ADMD is 'garr';
- DECnetネットワーク名(ネットの)は'OMNI'です。 - ゲートウェイ(gwnode)のDECnetノード名は'.IT.DM.X4TDEC'です。 Phase IVの別名'X4TDEC'。 - ゲートウェイのCountry Codeは'IT'です、そして、ADMDは'garr'です。
(and these two fields are enough to identify uniquely the gateway
within the X.400 MHS).
(これらの2つの分野がX.400 MHSの中で唯一ゲートウェイを特定するために十分です。)
C=it; ADMD=garr; DD.Dnet=OMNI;
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 .IT.DM.X4TDEC DECnet node).
(上記の例では、'EASYNET'によって.IT.DM.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 MIXER, and including this as 'f-address'. A 'f-pref' and a the DECnet node name of the gateway.
MIXERの支部4で定義されて、'f-アドレス'としてこれを含んでいるとしてX400テキストアドレスに様々な属性をコード化しながら、メール-11へのX.400O/Rアドレスに関するマッピングをします。 'f-pref'とノードが命名するゲートウェイのDECnet。
Allocchio Experimental [Page 18] RFC 2162 MaXIM-11 January 1998
Allocchio[18ページ]実験的なRFC2162格言1998年1月11日
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 '.IT.DM.X4TDEC'
alias 'X4TDEC' in Phase IV, and 'net' is 'OMNI'
- ゲートウェイ(gwnode)のDECnetノード名はPhase IVの'.IT.DM.X4TDEC'別名'X4TDEC'です、そして、'ネット'は'OMNI'です。
Thus
このようにして
C=gb; ADMD=G400; PRMD=AC.UK; O=ucl; S=Clay;
Cはgbと等しいです。 ADMD=G400。 PRMD=AC.UK。 O=ucl。 Sは粘土と等しいです。
will be encoded like
コード化された同類であるために望んでください。
X4TDEC::gw%"/C=gb/A=G400/P=AC.UK/O=ucl/S=Clay"
X4TDEC:、:「gw%gb/A=G400/P=AC.UK/O=ucl/S=」 /C=クレイ」
or its equivalent with the ";" notation and DECnet/OSI 'node'
「それが同等である、」、;、」 記法とDECnet/OSI'ノード'
OMNI:.IT.DM.X4TDEC::gw%"C=gb;ADMD=G400;PRMD=AC.UK;O=ucl;S=Clay;"
全、: .IT.DM.X4TDEC:、:gw%、「C=gb; ADMD=G400; PRMD=AC.UK; O=ucl; Sは粘土と等しいです」。
5.5. Mail-11 encoding of X.400 --> X.400
5.5. X.400のメール-11コード化-->X.400
It can happen 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つのケースを区別しなければなりません:
Allocchio Experimental [Page 19] RFC 2162 MaXIM-11 January 1998
Allocchio[19ページ]実験的なRFC2162格言1998年1月11日
- 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テキストアドレス」
or (for DECnet/OSI)
または(DECnet/OSIのための)
net: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)。
and (for DECnet/OSI)
そして(DECnet/OSIのための)
net:gwnode::gw%"x400-text-address"
ネット: gwnode:、:gw%、「x400テキストアドレス」
maps into
地図
C=xx; ADMD=yyy; DD.Dnet=net;
DD.Mail-11=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にもこのドメインを含めるのを待っている間、後者のケースを推奨しなく、可能な一時的な解決だけと見なさなければなりません。
Allocchio Experimental [Page 20] RFC 2162 MaXIM-11 January 1998
Allocchio[20ページ]実験的なRFC2162格言1998年1月11日
5.5.1. Examples
5.5.1. 例
Let us suppose that:
以下のことと思いましょう。
- the DECnet network name (net) is 'OMNI';
- the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC'
alias 'X4TDEC' in Phase IV;
- 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ネットワーク名(ネットの)は'OMNI'です。 - ゲートウェイ(gwnode)のDECnetノード名はPhase IVの'.IT.DM.X4TDEC'別名'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はモローと等しいです。
X4TDEC::gw%"C=zz;ADMD= ;PRMD=Botwa;O=Miner;S=Chiuaw;"
C=it; ADMD=garr; DD.Dnet=OMNI;
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 - Mapping - Mail-11 / RFC822
第6章--マッピング--メール-11 / RFC822
6.1 Introduction
6.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 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ゲートウェイは、多くのソフトウェア開発者によって独自に面していて、VMSとUNIXシステムの両方で動いていた多くのメール製品に含まれました。メール-11の実現--道、実現を写像するユニークな規格がなかったとき、結果になられて、メール-11を写像する多くの可能な異形方法がRFC822に1つを記述します。 多くの事実上のマッピング法を作成し始めて、これらのいくつかの製品が次に、主に広範囲になりました。
In this chapter 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. In case DECnet/OSI Mail-11 addresses are involved we must also notice that only one mapping method can be used from/to RFC822 addresses.
本章では、マッピング問題のある種の規格化が考えられます、ソフトをインストールした存在と互換性があるようになろうとして。 また、私たちは、いくつかの場合で簡単なメール11アドレスしかRFC822に写像できなかったように思い出させなければなりません、すべての種類のかなり奇妙な結果を生む複雑なものを持っていて。 DECnet/OSIメール-11アドレスがかかわるといけないので、また、私たちは、/からRFC822アドレスまで1つのマッピング法しか使用できないのに気付かなければなりません。
Allocchio Experimental [Page 21] RFC 2162 MaXIM-11 January 1998
Allocchio[21ページ]実験的なRFC2162格言1998年1月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::]...]prot::"rfc-822-address"
[ノード:、:、]、[ノード:、:、]、…「]、prot:、:、」「rfc822アドレス」
or again for DECnet/OSI addresses
または、再びDECnet/OSIアドレスのために
[net:][node-clns::]prot%"rfc-822-address"
[以下を網状にならせます]、[ノード-clns:、:、]、prot%、「rfc822アドレス」
or
または
[net:][node-clns::]prot::"rfc-822-addres"
「[以下を網状にならせます]、[ノード-clns:、:、]、prot:、:、」"rfc-822-addres"
6.2 De facto implementations
6.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. This method applies also
easily to DECnet/OSI Mail-11 addresses.
a--このフォームは引用されたLeft Hand Sideストリングとして単にメール-11/RFC822ゲートウェイのRFC822アドレスにオリジナルのメール-11アドレスを同封します。 この方法はRFC822構文で完全にconformantです、そして、メール-11アドレスは触れない状態で残されます。 したがって、どんな符号化規則も、それに適用されていた状態で必要がありません。 この方法は容易にもDECnet/OSIメール-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)アドレスの同様のコード化から区別がつかなくなります。その結果、それは非難されるべきです。
Allocchio Experimental [Page 22] RFC 2162 MaXIM-11 January 1998
Allocchio[22ページ]実験的なRFC2162格言1998年1月11日
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のアドレスを写像できません、そして、アドレスの'ドメイン'部分を加えるためのどんな特定の規則もありません。
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のアドレスをこの構文に埋め込むことができません。
Note the only methods a) can be successfully used for DECnet/OSI Mail-11 addresses, while the other cases are already too complex to encode in a unique way such addresses in RFC822.
DECnet/OSIメール-11アドレスに首尾よく唯一の方法a)を使用できることに注意してください、他のケースは既にユニークな方法でRFC822のそのようなアドレスをコード化できないくらい複雑ですが。
6.3 Recommended mappings
6.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の間のマッピングを表すために標準形を引き出すことができます。
6.3.1 RFC822 mapped in Mail-11
6.3.1 メール-11で写像されたRFC822
The mapping of an RFC822 address in Mail-11 is straightforward, using the "Mail-11 foreign mail protocol" syntax. The two possible variants for Phase IV are:
「メール-11の外国メールプロトコル」構文を使用して、メール-11におけるRFC822アドレスのマッピングは簡単です。 2つのPhase IVに、可能な異形は以下の通りです。
[[node::][node::]...]prot%"rfc-822-address"
[ノード:、:、]、[ノード:、:、]、prot%、「rfc822アドレス」
or
または
[node::][node::]...]prot::"rfc-822-address"
[ノード:、:、]、[ノード:、:、]、…「]、prot:、:、」「rfc822アドレス」
The equivalent two possible variants for DECnet/OSI are:
2つの同等なDECnet/OSIに、可能な異形は以下の通りです。
[net:][node-clns::]prot%"rfc-822-address"
[以下を網状にならせます]、[ノード-clns:、:、]、prot%、「rfc822アドレス」
or
または
[net:][node-clns::]prot::"rfc-822-address"
「[以下を網状にならせます]、[ノード-clns:、:、]、prot:、:、」「rfc822アドレス」
Allocchio Experimental [Page 23] RFC 2162 MaXIM-11 January 1998
Allocchio[23ページ]実験的なRFC2162格言1998年1月11日
6.3.2 Mail-11 mapped in RFC822
6.3.2 RFC822で写像されたメール-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 both for Phase IV and DECnet/OSI is:
RFC822は非RFC822アドレスを表すために標準形について見通します: 置かれて、地方の部分(Hand Side、LHSに残される)の外国アドレスはできるだけオリジナルの構文と同様のフォームです。 したがって、Phase IVとDECnet/OSIのための提案されたマッピングは以下の通りです。
"Mail-11-address"@gateway-address
「メール11アドレス」@gatewayアドレス
This format assures also the return path via the appropriate gateway.
また、この形式は適切なゲートウェイを通してリターンパスを保証します。
6.3.3 Mail-11 (foreign mail protocol) mapped in RFC822
6.3.3 RFC822で写像されたメール-11(外国メールプロトコル)
A Mail-11 address containing a foreign mail protocol syntax can also contain the percent '%' character as a separator between the foreign protocol name and the actual address itself. In some cases the address part can also be an unquoted string. Some examples:
また、外国メールプロトコル構文を含むメール-11アドレスは分離符として外国プロトコル名と絶対番地自体の間にパーセント'%'キャラクタを含むことができます。 また、いくつかの場合、アドレス部は引用を終わっているストリングであるかもしれません。 いくつかの例:
deliver%swan
myprot%root.owner
listserv%my-private.list.A1
%白鳥myprot%root.owner listservに%を渡してください、私、-、private.list.A1
If these addresses are encoded into an RFC822 address using the "natural" method described in 6.3.2, they will result in something which can be easily mismatched with an address using the percent hack in LHS for source routing.
これらのアドレスが中で説明された「自然な」方法を使用することでRFC822アドレスにコード化される、6.3、.2、それらはアドレスがソースルーティングにLHSでパーセントハッキングを使用している状態で容易にミスマッチできる何かをもたらすでしょう。
"myprot%root.owner"@lohost.mydom.edu (Mail-11 address)
「myprot%root.owner」@lohost.mydom.edu(メール-11アドレス)
"LISTSERV%IBMB.BITnet"@bitgate.anu.edu (% routing address)
「リストサーブ%IBMB.BITnet」@bitgate.anu.edu(アドレスを発送する%)
The percent hack is strongly deprecated, and thus should be avoided; the second address above shoud be expressed as:
パーセントハッキングは、強く非難されて、その結果、避けられるべきです。 2番目のアドレス、shoudの上では、以下として言い表されてください。
@bitgate.anu.edu:"LISTSERV@IBMB.BITnet"
@bitgate.anu.edu: " LISTSERV@IBMB.BITnet "
However, in order to assure maximum functionality and avoid problems, it is recommended to encode Mail-11 addresses containing the foreign protocol specification in RFC822 syntax using the DD.Mail-11 and DD.dnet qualifiers, i.e.
しかしながら、最大の機能性を保証して、問題を避けるために、DD.Mail-11を使用することでRFC822構文による外国プロトコル仕様を含むメール-11のアドレスとDD.dnet資格を与える人をコード化するのはすなわち、お勧めです。
"/DD.Mail-11=myprot%root.owner/DD.dnet=OMNI"@lohost.mydom.edu
「/DD.Mail-11=myprot%root.owner/DD.dnetが等しい、全、」 @lohost.mydom.edu
The DD.dnet defaults as indicated in the similar cases for the Mail-
11 / X.400 mappings. This encoding method can, of course, also be
used to map any other Mail-11 address in RFC822, and is the only one
which enable to specify the network name ('OMNI' in the above
example) for DECnet Phase IV Mail-11 addresse. The method is fully
DD.dnetはメール11 / X.400マッピングのための類例にみられるようにデフォルトとします。 このコード化方法は、また、RFC822のいかなる他のメール-11アドレスも写像するのにもちろん使用できて、ネットワーク名(上記の例の'OMNI')をDECnet Phase IVメール-11addresseに指定するのを可能にする唯一無二です。 方法は完全にそうです。
Allocchio Experimental [Page 24] RFC 2162 MaXIM-11 January 1998
Allocchio[24ページ]実験的なRFC2162格言1998年1月11日
compatible with the results also produced by gateways following the MIXER specification for Mail-11 addresses encoded in X.400 and then translated into RFC822.
また、X.400でコード化されたメール-11のアドレスのためのMIXER仕様に従って、ゲートウェイによって生産されて、次に、RFC822に翻訳された結果と互換性があります。
Chapter 7 - Complex mapping - X.400 / Mail-11 / RFC822
第7章--複雑なマッピング--メールX.400/11 / RFC822
7.1. The protocol triangle
7.1. プロトコル三角形
The bilateral mappings described in chapters 5 and 6 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章と第6章で説明された双方のマッピングを広げなければなりません、そして、以下の三者間の状況は起こります:
X.400
/ \
/ \
/ \
Mail-11----RFC822
/\/\メール-11X.400/円----RFC822
The X.400 - RFC822 side is fully covered by MIXER, and the previous chapters in this document cover the Mail-11 - X.400 side and the Mail-11 - RFC822 one.
X.400--RFC822側はMIXERで完全にカバーされていて、前の章は本書ではメール-11--X.400側とメール-11--RFC822 1を覆っています。
7.2. RFC822 mapped in Mail-11
7.2. メール-11で写像されたRFC822
The 'RFC822-address' is usually included in 'local-part' as
通常、'RFC822-アドレス'は'地方の部分'に含まれています。
route::gwnode::gw%"rfc822-address"
以下を発送してください:gwnode:、:%が「rfc822記述する」gw
or the equivalent in DECnet/OSI:
DECnet/OSIの同等物:
net:gwnode::gw%"rfc822-address"
ネット: gwnode:、:%が「rfc822記述する」gw
An example in Phase IV
Phase IVの例
NVXA23::SMTPGW::in%"M.T.Rose@CS.UCLA.edu"
NVXA23:、:SMTPGW:、:インチ" M.T.Rose@CS.UCLA.edu "
and another one in DECnet/OSI
そして、DECnet/OSIの別の1つ
OMNI:.FR.INET.LABOL.SMTPGW::in%"M.T.Rose@CS.UCLA.edu"
全、: .FR.INET.LABOL.SMTPGW:、:インチ" M.T.Rose@CS.UCLA.edu "
7.3. Mail-11 mapped in RFC822
7.3. RFC822で写像されたメール-11
There are different styles in mapping a Mail-11 address in RFC822; let's have a short summary of what was traditionally done in some implementations.
メール-11アドレスを写像するのにおいて異なったスタイルがRFC822にあります。 いくつかの実現で伝統的に行われたことに関する要約を持ちましょう。
Allocchio Experimental [Page 25] RFC 2162 MaXIM-11 January 1998
Allocchio[25ページ]実験的なRFC2162格言1998年1月11日
7.3.1 Mail-11 address encoded in "Left Hand Side" (LHS) of RFC822
address, using "%" syntax or "::" syntax
または、「7.3.1 「%」構文を使用して、メール-11アドレスが「左側」でRFC822アドレスの(LHS)をコード化した、」、:、:、」 構文
route::node::localpart (Phase IV)
以下を発送してください:ノード:、:localpart(フェーズIV)
maps to
地図
localpart%node%route@gw-domains
localpart%node%route@gw-domains
or
または
"route::node::localpart"@gw-domains
「以下を発送してください」ノード:、:"localpart"@gwドメイン
Again, let's consider the DECnet/OSI case:
一方、DECnet/OSIケースを考えましょう:
net:node-clns::localpart (DECnet/OSI)
ネット: ノード-clns:、:localpart(DECnet/OSI)
maps to
地図
"net:node-clns::localpart"@gw-domains
「ネット: ノード-clns:、:、」"localpart"@gwドメイン
(note that "%" encoding does not exist for this case)
(「%」コード化がこのような場合存在していないというメモ)
where 'gw-domains' identify uniquely the Mail-11 / RFC822 gateway.
'gw-ドメイン'が唯一メール-11 / RFC822ゲートウェイを特定するところ。
7.3.2 Mail-11 address maps partly to LHS and partly to 'domain' part of
RFC822 address
7.3.2 一部LHSと、そして、一部RFC822アドレスの'ドメイン'部分へのメール-11のアドレス地図
node::localpart
ノード:、:localpart
maps to
地図
localpart@node.gw-domains
localpart@node.gw-domains
note that this kind of mapping does not exists with DECnet/OSI Mail- 11 addresses.
この種類に関するマッピングがそうしないというメモはDECnet/OSIメール11アドレスで存在しています。
7.3.3 Mail-11 address is completely hidden by a mapping table
7.3.3メール-11アドレスはマッピングテーブルに完全に隠れています。
In this case the resultant RFC822 address contains no trace at all of the original Mail-11 address.
この場合、結果のRFC822アドレスはオリジナルのメール-11アドレスのすべてに跡を全く含みません。
Allocchio Experimental [Page 26] RFC 2162 MaXIM-11 January 1998
Allocchio[26ページ]実験的なRFC2162格言1998年1月11日
7.4. Multiple conversions
7.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つがもう片方にばらばらになっている変換であると盲目的に考えるのはいつも使用できます。
7.4.1. X.400 --> RFC822 --> Mail-11
7.4.1. X.400-->RFC822-->メール-11
We apply the MIXER 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 7.2.
私たちはMIXER規則を第一歩に適用します、メール-11で'f-アドレス'分野を使用することで写像できるRFC822アドレスを得て、セクション7.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 MIXER to
それに従って、MIXERへの写像
Jim.Clay@cs.UCL.AC.UK
Jim.Clay@cs.UCL.AC.UK
and finally becomes
最終的に、なります。
SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK"
SMTPGW:、:インチ" Jim.Clay@cs.UCL.AC.UK "
and finally becomes
最終的に、なります。
SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK"
SMTPGW:、:インチ" Jim.Clay@cs.UCL.AC.UK "
where 'SMTPGW' is the DECnet Phase IV node name of the machine running the RFC822 to Mail-11 gateway. Again, in case the machine running the RFC822 to Mail-11 gateway is a DECnet/OSI one (like OMNI:.US.VA.CENTRL) we would get
'SMTPGW'がメール-11ゲートウェイへRFC822を走らせるマシンのDECnet Phase IVノード名であるところ。 一方、場合では、メール-11ゲートウェイへRFC822を走らせるマシンは私たちが手に入れるDECnet/OSI1です(OMNI: .US.VA. CENTRLのような)。
OMNI:.US.VA.CENTRL::In%"Jim.Clay@cs.UCL.AC.UK"
全、: .US.VA. CENTRL:、:インチ" Jim.Clay@cs.UCL.AC.UK "
7.4.2. Mail-11 --> RFC822 --> X.400
7.4.2. メール-11-->RFC822-->X.400
Some of the possible mapping described in section 7.3 for Phase IV apply to the Mail-11 address, hiding completely its origin. The MIXER apply on the last step.
Phase IVのためにセクション7.3で説明された可能なマッピングのいくつかがメール-11アドレスに適用されます、完全に正体を隠して。 MIXERは最後のステップのときに適用します。
Allocchio Experimental [Page 27] RFC 2162 MaXIM-11 January 1998
Allocchio[27ページ]実験的なRFC2162格言1998年1月11日
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 MIXER
それに従って、MIXER
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ゲートウェイへ走らせるマシンのドメインであるところ。
7.4.3. X.400 --> Mail-11 --> RFC822
7.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' nto the Mail-11 address, then it applies MIXER to it, and encodes header. Otherwise it applies the rules described in 7.3.
X.400アドレスはセクション5.3と5.4で説明されるようにメール-11'f-アドレス'要素に格納されます。 次に、RFC822ゲートウェイへのメール-11がメール-11が記述する'x400テキストアドレス'ntoの存在を理解できるなら、それは、MIXERをそれに適用して、ヘッダーをコード化します。 さもなければ、それは7.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 MIXER
RFC822ゲートウェイへのメール-11がx400テキストアドレスを認識するなら、アドレスはそれに従って、MIXERになります。
Jim.Clay@cs.UCL.AC.UK
Jim.Clay@cs.UCL.AC.UK
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と等しいです。
The case with DECnet/OSI Mail-11 is conceptually identical.
DECnet/OSIメール-11があるケースは概念的に同じです。
Allocchio Experimental [Page 28] RFC 2162 MaXIM-11 January 1998
Allocchio[28ページ]実験的なRFC2162格言1998年1月11日
7.4.4. RFC822 --> Mail-11 --> X.400
7.4.4. RFC822-->メール-11-->X.400
The RFC822 address is encoded in Mail-11 f-address element as described in sect. 7.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 MIXER to it, and encodes 'route' and applies the rules described in 5.2 and 5.5.
RFC822アドレスはセクトで説明されるようにメール-11f-アドレス要素でコード化されます。 7.2; 次に、X.400ゲートウェイへのメール-11が'RFC822-アドレス'の存在をメール-11アドレスに理解できるなら、それは、MIXERをそれに適用して、'ルート'をコード化して、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 MIXER
X.400ゲートウェイへのメール-11がRFC822-アドレスを認識するなら、アドレスはそれに従って、MIXERになります。
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)
Again, the case for DECnet/OSI Mail-11 addresses, is conceptually identical.
DECnet/OSIメール-11アドレスのための再び、ケースは概念的に同じです。
7.4.5. RFC822 --> X.400 --> Mail-11
7.4.5. RFC822-->X.400-->メール-11
We apply MIXER 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アドレスを得て、私たちは最初の変換にMIXERを適用します。 そして、セクション5.3と5.4で説明された規則は、'x400テキストアドレス'としてメール-11にX.400アドレスを格納するのに使用されます。
Allocchio Experimental [Page 29] RFC 2162 MaXIM-11 January 1998
Allocchio[29ページ]実験的なRFC2162格言1998年1月11日
an example:
例:
Jim.Clay@cs.UCL.AC.UK
Jim.Clay@cs.UCL.AC.UK
maps accordingly to MIXER to
それに従って、MIXERへの写像
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 Phase IV node name of the machine running the X.400 to Mail-11 gateway. No differences also for DECnet/OSI Mail-11 addresses.
'SMTPGW'がメール-11ゲートウェイへX.400を走らせるマシンのDECnet Phase IVノード名であるところ。 DECnet/OSIメール-11アドレスのために違いがありませんも。
7.4.6. Mail-11 --> X.400 --> RFC822
7.4.6. メール-11-->X.400-->RFC822
The Mail-11 address is encoded as specified in sections 5.2 and 5.5; then MIXER is used to convert the address in RFC822.
メール-11アドレスはセクション5.2と5.5で指定されるようにコード化されます。 そして、MIXERは、RFC822のアドレスを変換するのに使用されます。
an example:
例:
RELAY::MYNODE::BETTY
以下をリレーしてください:MYNODE:、:ベティ
maps into X.400 as
X.400への地図
C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=RELAY::MYNODE::BETTY;
Cはそれと等しいです。 ADMD=garr。 DD.Dnetが等しい、全、。 DD.Mail-11=は以下をリレーします:MYNODE:、:ベティ。
and accordingly to MIXER
それに従って、MIXER
"/C=it/A=garr/DD.Dnet=OMNI/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 MIXER gateway.
'gw2.it'がMIXERゲートウェイを動かすマシンのドメインであるところ。
7.4. Conclusions
7.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 it could be impossible (in case of DECnet Phase IV) to specify in these mappings the name of the decnet community owning the encoded address, as it can be always done for X.400; thus the implementation of the 'intelligent' gateway in this case could result impossible.
メール-11のアドレスをRFC822に写像する標準の方法は逆もまた同様に可能です。 すべての存在と今後の実現を統一するのを提案をこのようにしてします。 しかしながら、これらのマッピングでコード化されたアドレスを所有しているdecnet共同体の名前を指定するのが不可能であるかもしれないことに(DECnet Phase IVの場合の)注意されるべきです、X.400のためにいつもそれができるように。 その結果、'知的'ゲートウェイの実現はこの場合不可能であることができました。結果不可能です。
Allocchio Experimental [Page 30] RFC 2162 MaXIM-11 January 1998
Allocchio[30ページ]実験的なRFC2162格言1998年1月11日
Chapter 8 - Notifications and Probes
第8章--通知と徹底的調査
8.1. Overview
8.1. 概観
Mail-11 is a real time protocol, i.e. connection is established directly to the destination node. This makes possible some level of services like verification of an address, and delivery confirmation.
メール-11がリアルタイムのプロトコルである、すなわち、接続は直接目的地ノードを確立されます。 これで、何らかのアドレス、および配送確認の検証のようなサービスのレベルが可能になります。
However, Mail-11 User Agents ususally do not support notification or probe services, whereas it is possible to deliver the result of a notification or a probe to Mail-11. In this section we will briefly describe the level of service which can be obtained on these services when Mail-11 is involved.
しかしながら、メール-11人のUserエージェントは、ususallyに通知を支持もしませんし、サービスを調べもしませんが、通知か徹底的調査の結果をメール-11に送るのは可能です。 このセクションで、私たちは簡潔にメール-11がこれらのサービスのときに伴われるとき得ることができるサービスのレベルについて説明するつもりです。
8.2. Delivery of Notifications via Mail-11
8.2. メール-11を通したNotificationsの配送
As described in the previous chapters, it is possible to transport also in Mail-11 with minimal loss of information complex information. This also includes Notifications. In fact Notifications in RFC822/MIME are encoded as MIME multipart messages: there are thus no problems in transporting these messages in Mail-11 as any other MIME message. Also X.400 Notifications can be transported and delivered via Mail-11: MIXER describes in fact how to convert them into MIME multipart messages, taking the problem back to the previous situation.
前の章で説明されるように、それはまた、情報の複雑な情報の最小量の損失でメール-11で輸送するのにおいて可能です。 また、これはNotificationsを含んでいます。 事実上、RFC822/MIMEにおけるNotificationsはMIMEの複合メッセージとしてコード化されます: その結果、これらのメッセージを輸送するのにおいてメール-11にはいかなる他のMIMEメッセージとしても問題が全くありません。 また、メール-11でX.400 Notificationsを輸送して、届けることができます: 事実上、MIXERは前の状況に問題を取り消して、MIMEの複合メッセージにそれらを変換する方法を説明します。
Even when Mail-11 is just an intermediate step for a Notification message, this consideration just enable support for the service.
メール-11がそうときにさえ、Notificationメッセージのためのまさしく途中経過、この考慮はただサービスのサポートを可能にします。
8.3. Generation of Notifications and Probes from Mail-11
8.3. メール-11からの通知と徹底的調査の世代
Although Mail-11 does not support Notification or Probe, the service could also be supported at gateway level. In fact, due to real time nature of Mail-11 protocol, the gateway could be reasonably sure that delivery until the other end of the Mail-11 path was successful or unsuccessful (and try to verify the feasibility of a delivery in case a Probe as requested). However, Mail-11 could just be an intermediate relay service, vanishing the value of the information.
メール-11はNotificationかProbeを支持しませんが、また、ゲートウェイレベルでサービスを支持できました。 事実上、メール-11プロトコルのリアルタイムの本質のために、メール-11経路のもう一方の端がうまくいくか、または失敗するまで(要求された通りケースa Probeの配送に関する実現の可能性について確かめるようにしてください)、ゲートウェイは合理的に確実にその配送であるかもしれません。 しかしながら、情報の価値を消えさせて、メール-11はまさしく中間的リレーサービスであるかもしれません。
Implementation of this kind of service at gateway level is thus questionable, and if done, should clearly state the situation where it was generated, and the "confidence level" it conveys.
その結果、ゲートウェイレベルにおける、この種類のサービスの実現は疑わしいです、そして、するなら、明確にそれが発生した状況、およびそれが伝える「信頼水準」を述べるべきです。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Allocchio Experimental [Page 31] RFC 2162 MaXIM-11 January 1998
Allocchio[31ページ]実験的なRFC2162格言1998年1月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. E. Kille.
最初の草稿を読み込んで、彼らの役に立つ提案でこのドキュメントの改正に大いに貢献したすべての人々に感謝申し上げます、IETF X.400オプアートの特定のRARE WG1、グループのメンバー、およびS.E.Killeで。
Thanks also to a number of implementors (among which Ned Freed, Julian Onions, The Hebrew University of Tel Aviv - Pine VMS support team), to the HEPnet Mail Technical Committee and to all my Mail-11 "end users", in particular Enzo Valente, for their suggestions and wishes which helped me really a lot to prepare this revision of former RFC1405.
また、多くの作成者(フリード、ジュリアン・アニアンズ、テルアビブのヘブライのどのネッドの大学の中で--松のVMSはチームを支持するか)と、そして、HEPnetメールTechnical Committeeと、そして、私のすべてのメール-11「エンドユーザ」と、彼らの提案のための特にエンツォ・バレンテと元RFC1405のこの改正を準備するために本当に私を大いに助けたお言葉をありがとうございます。
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] CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1,"
Message Handling: System and Service Overview , December 1992.
[3]CCITT/ISO、「CCITT推薦X.400/ ISOは10021-1です」、メッセージハンドリング: システムとサービス概観、1992年12月。
[4] Crocker D., "Standard of the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDel, August 1982.
[4] 医者D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDel、1982年8月。
[5] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
Mapping between X.400 and RFC 822/MIME", RFC 2156, January
1998.
[5]Kille、S.、「ミキサー(パントマイムインターネットX.400はリレーを機能アップしました):」 「X.400とRFC822/の間でMIMEを写像します」、RFC2156、1998年1月。
[6] Alvestrand H., Kille S., Miles R., Rose M., and Thompson S.,
(MIME-MHS) "Mapping between X.400 and RFC-822 Message Bodies,"
RFC 1495, Aug 1993.
[6] Alvestrand H.、Kille S.、マイルR.、ローズM.、およびトンプソンS.、「X.400とRFC-822メッセージボディーの間のマッピング」、(MIME-MHS)RFC1495(1993年8月)。
[7] Digital Equipment Corp., "VMS Mail Utility".
[7] ディジタル・イクイップメント社、「VMSはユーティリティを郵送します」。
[8] Joiner Associates Inc., "Jnet User's Manual".
[8] Joinerは株式会社、「Jnetユーザマニュアル」を関連づけます。
[9] PMDF User's Guide.
[9] PMDF使用手引書。
[10] Alvestrand, H. "Writing X.400 O/R Names", UNINETT / RFC1685,
August 1994.
[10]Alvestrand、H.「書くことのX.400O/R名」、UNINETT / RFC1685、1994年8月。
[11] CCITT, "F.401 CCITT Message Handling Services - Operations and
Definitions of Service - Naming and Addressing for Public
Message Handling Services, Annex B (08/92)", August 1992.
[11] CCITT、「F.401CCITTメッセージハンドリングは公共のメッセージ通信処理サービスのための命名とアドレシングを修理します(サービスの操作と定義)、別館B(08/92)」、1992年8月。
Allocchio Experimental [Page 32] RFC 2162 MaXIM-11 January 1998
Allocchio[32ページ]実験的なRFC2162格言1998年1月11日
Author's Address
作者のアドレス
Claudio Allocchio Sincrotrone Trieste SS 14 Km 163.5 Basovizza I 34012 Trieste Italy
クラウディオAllocchio SincrotroneトリエステSS14km163.5Basovizza I34012トリエステイタリア
Phone: +39 40 3758523
Fax: +39 40 3758565
EMail: Claudio.Allocchio@elettra.Trieste.it
C=it; A=garr; P=Trieste; O=Elettra; S=Allocchio; G=Claudio;
以下に電話をしてください。 +39 40 3758523、Fax: +39 40 3758565はメールされます: Claudio.Allocchio@elettra.Trieste.it Cはそれと等しいです。 A=garr。 Pはトリエステと等しいです。 Oはエレットラと等しいです。 S=Allocchio。 Gはクラウディオと等しいです。
Allocchio Experimental [Page 33] RFC 2162 MaXIM-11 January 1998
Allocchio[33ページ]実験的なRFC2162格言1998年1月11日
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Allocchio Experimental [Page 34]
Allocchio実験的です。[34ページ]
一覧
スポンサーリンク
