RFC1664 日本語訳
1664 Using the Internet DNS to Distribute RFC1327 Mail Address MappingTables. C. Allocchio, A. Bonito, B. Cole, S. Giordano, R. Hagens. August 1994. (Format: TXT=50783 bytes) (Obsoleted by RFC2163) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Allocchio
Request for Comments: 1664 A. Bonito
Category: Experimental GARR-Italy
B. Cole
Cisco Systems Inc.
S. Giordano
Centro Svizzero Calcolo Scientifico
R. Hagens
Advanced Network & Services
August 1994
Allocchioがコメントのために要求するワーキンググループC.をネットワークでつないでください: 1664年のA.かつおのカテゴリ: 実験的なガー-イタリアB.コールシスコシステムズ株式会社S.ジョルダーノセントロSvizzero Calcolo Scientifico R.Hagensは1994年8月にネットワークとサービスを唱えました。
Using the Internet DNS to Distribute
RFC1327 Mail Address Mapping Tables
テーブルを写像するRFC1327郵便の宛先を配布するのにインターネットDNSを使用します。
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This memo defines how to store in the Internet Domain Name System the mapping information needed by e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. Mapping information can be managed in a distributed rather than a centralised way. Gateways located on Internet hosts can retrieve the mapping information querying the DNS instead of having fixed tables which need to be centrally updated and distributed. This memo is a joint effort of X400 operation working group (x400ops) and RARE Mail and Messaging working group (WG-MSG).
このメモはインターネットドメインネームシステムにメールゲートウェイによって必要とされたマッピング情報と逆もまた同様にX.400O/R名にRFC822ドメイン名を写像する他のツールを収納する方法を定義します。 集中化されているというよりむしろ分配された方法でマッピング情報に対処できます。 インターネット・ホストの上に位置するゲートウェイは中心でアップデートして、分配する必要がある固定テーブルを持っていることの代わりにDNSについて質問するマッピング情報を検索できます。 このメモはX400操作ワーキンググループ(x400ops)、RAREメール、およびMessagingワーキンググループ(WG-MSG)の共同努力です。
1. Introduction
1. 序論
The connectivity between the Internet SMTP mail and other mail services, including the Internet X.400 mail and the commercial X.400 service providers, is assured by the Mail eXchanger (MX) record information distributed via the Internet Domain Name System (DNS). A number of documents then specify in details how to convert or encode addresses from/to RFC822 style to the other mail system syntax. However, only conversion methods provide, via some algorithm or a set of mapping rules, a smooth translation, resulting in addresses indistinguishable from the native ones in both RFC822 and foreign world.
インターネットX.400メールと商業X.400サービスプロバイダーを含むインターネットSMTPメールと他のメールサービスの間の接続性はeXchanger(MX)がインターネットドメインネームシステム(DNS)で分配された情報を記録することがメールによって保証されます。 そして、多くのドキュメントが詳細に/からRFC822スタイルまでもう片方のメールシステム構文にアドレスを変換するか、またはコード化する方法を指定します。 しかしながら、変換法だけが提供されます、何らかのアルゴリズムか配置規則のセットを通して、滑らかな翻訳、RFC822と外国世界の両方のネイティブのものから区別できないアドレスをもたらして。
RFC1327 describes a set of mappings which will enable interworking between systems operating the CCITT X.400 (1984/88) Recommendations
RFC1327はCCITT X.400(1984/88)推薦を操作するシステムの間の織り込むことを可能にする1セットのマッピングについて説明します。
Allocchio, Bonito, Cole, Giordano & Hagens [Page 1] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[1ページ]RFC1664インターネット
and systems using the RFC822 mail protocol, or protocols derived from RFC822. That document addresses conversion of services, addresses, message envelopes, and message bodies between the two mail systems. This document is concerned with one aspect of RFC1327: the mechanism for mapping between X.400 O/R addresses and RFC822 domain names. As described in Appendix F of RFC1327, implementation of the mappings requires a database which maps between X.400 O/R addresses and domain names, and this database is statically defined.
そして、RFC822メールプロトコル、またはRFC822から得られたプロトコルを使用するシステム。 そのドキュメントは2台のメールシステムの間のサービス、アドレス、メッセージ封筒、およびメッセージ本体の変換を記述します。このドキュメントはRFC1327の1つの局面に関係があります: X.400O/RのアドレスとRFC822の間でドメイン名を写像するためのメカニズム。 RFC1327のAppendix Fで説明されるように、マッピングの実現はX.400O/Rの間でアドレスとドメイン名を写像するデータベースを必要とします、そして、このデータベースは静的に定義されます。
This approach requires many efforts to maintain the correct mapping: all the gateways need to get coherent tables to apply the same mappings, the conversion tables must be distributed among all the operational gateways, and also every update needs to be distributed. This static mechanism requires quite a long time to be spent modifying and distributing the information, putting heavy constraints on the time schedule of every update. In fact it does not appear efficient compared to the Internet Domain Name Service (DNS). More over it does not look feasible to distribute the database to a large number of other useful applications, like local address converters, e-mail User Agents or any other tool requiring the mapping rules to produce correct results.
このアプローチは正しいマッピングを維持するための多くの努力を必要とします: すべてのゲートウェイが、一貫性を持っているテーブルに同じマッピングを適用させる必要があります、そして、すべての操作上のゲートウェイの中で変換テーブルを分配しなければなりません、そして、あらゆるアップデートも分配される必要があります。 この静止機構は情報を変更して、分配するのに費やされるべきかなり長い時間を必要とします、あらゆるアップデートの時間割に重い規制を置いて。 事実上、インターネットDomain Name Service(DNS)と比べて、それは効率的に見えません。 それの上の以上は他の多くの役に立つアプリケーションにデータベースを分配するのにおいて可能に見えません、ローカルアドレスコンバータ、メールUserエージェントまたは生産するために配置規則を必要とするいかなる他のツールも結果を修正するように。
A first proposal to use the Internet DNS to store, retrieve and maintain those mappings was introduced by two of the authors (B. Cole and R. Hagens) adopting two new DNS resource record (RR) types: TO- X400 and TO-822. This new proposal adopts a more complete strategy, and requires one new RR only. The distribution of the RFC1327 mapping rules via DNS is in fact an important service for the whole Internet community: it completes the information given by MX resource record and it allows to produce clean addresses when messages are exchanged among the Internet RFC822 world and the X.400 one (both Internet and Public X.400 service providers).
それらのマッピングを格納して、検索して、維持するのにインターネットDNSを使用するという最初の提案は2の新しいDNSリソース記録(RR)タイプを採用しながら、2人の作者(B.コールとR.Hagens)によって紹介されました: -、X400で-822です。 この新規案件は、より完全な戦略を採用して、1新しいRRだけを必要とします。 事実上、DNSを通したRFC1327配置規則の分配は全体のインターネットコミュニティのための大任です: それはMXリソース記録によって与えられた情報を完成します、そして、インターネットRFC822世界とX.400 1(インターネットとPublic X.400サービスプロバイダーの両方)の中でメッセージを交換するとき、清潔なアドレスを生産物に許容します。
A first experiment in using the DNS without expanding the current set of RR and using available ones was in the mean time deployed by some of the authors. The existing PTR resource records were used to store the mapping rules, and a new DNS tree was created under the ".it" top level domain. The result of the experiment was positive, and a few test applications ran under this provisional set up. This test was also very useful in order to define a possible migration strategy during the deployment of the new DNS containing the new RR. The Internet DNS nameservers wishing to provide this mapping information need in fact to be modified to support the new RR type, and in the real Internet, due to the large number of different implementations, this takes some time.
RRの現在のセットを膨張させて、利用可能なものを使用しないでDNSを使用することにおける最初の実験はその間に何人かの作者によって配備されました。 既存のPTRリソース記録は配置規則を格納するのに使用されました、そして、新しいDNS木は".it"トップ・レベル・ドメインの下で作成されました。 実験の結果は上向きでした、そして、セットアップされて、いくつかのテストアプリケーションが暫定的にこれで実行されました。 また、このテストも、展開の間の新しいDNSが新しいRRを含む可能な移動戦略を定義するために非常に役に立ちました。 事実上、このマッピング情報を提供したがっているインターネットDNSネームサーバは、新しいRRタイプを支持するように変更される必要があります、そして、本当のインターネットでは、多くの異なった実現のため、これはある程度時間がかかっています。
The basic idea is to adopt a new DNS RR to store the mapping information. The RFC822 to X.400 mapping rules (including the so
基本的な考え方はマッピング情報を格納するために新しいDNS RRを採用することです。 X.400配置規則へのRFC822、(包含、そのように。
Allocchio, Bonito, Cole, Giordano & Hagens [Page 2] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[2ページ]RFC1664インターネット
called 'gate' rules) will be stored in the ordinary DNS tree, while the definition of a new branch of the name space defined under each national top level domain is envisaged in order to contain the X.400 to RFC822 mappings. A "two-way" mapping resolution schema is thus fully implemented.
呼ばれた'ゲート'規則) 普通のDNS木に格納されるでしょう、それぞれの国家のトップ・レベル・ドメインの下で定義された名前スペースの新しいブランチの定義はRFC822マッピングにX.400を含むように考えられますが。 「両用」のマッピング解決図式はこのようにして完全に実行されます。
The creation of the new domain name space representing the X.400 O/R names structure also provides the chance to use the DNS to distribute dynamically other X.400 related information, thus solving other efficiency problems currently affecting the X.400 MHS service.
また、構造というX.400O/R名を表す新しいドメイン名スペースの創造はダイナミックに他のX.400関連情報を分配するのにDNSを使用する見込みを提供します、その結果、現在X.400 MHSサービスに影響することにおける他の効率問題を解決します。
In this paper we will adopt the RFC1327 mapping rules syntax, showing how it can be stored into the Internet DNS.
この紙では、私たちはRFC1327配置規則構文を採用するつもりです、どうそれを格納できるかをインターネットDNSに招き入れて。
1.1 Definitions syntax
1.1定義構文
The definitions in this document is given in BNF-like syntax, using the following conventions:
BNFのような構文で、以下のコンベンションを使用して、与えられていますこれとの定義が、ドキュメントである:
| means choice
\ is used for continuation of a definition over several lines
[] means optional
{} means repeated one or more times
| 手段特選している\がいくつかの線[]手段の上のa定義の継続に任意の状態で使用される、手段は1回以上繰り返されました。
The definitions, however, are detailed only until a certain level, and below it self-explaining character text strings will be used.
定義で、しかしながら、あるレベルまでしか詳しく述べられないで、それの下で自己にキャラクタテキスト文字列が使用されるのがわかっています。
2. Motivation
2. 動機
Implementations of RFC1327 gateways require that a database store address mapping information for X.400 and RFC822. This information must be disseminated to all RFC1327 gateways. In the Internet community, the DNS has proven to be a practical mean for providing a distributed name service. Advantages of using a DNS based system over a table based approach for mapping between O/R addresses and domain names are:
RFC1327ゲートウェイの実現は、データベースがX.400とRFC822のためのアドレスマッピング情報を格納するのを必要とします。 すべてのRFC1327ゲートウェイにこの情報を広めなければなりません。 インターネットコミュニティでは、DNSは、分配された名前サービスを提供するための実用的な平均であると判明しました。 O/Rアドレスとドメイン名の間で写像されるテーブルの上のDNSのベースのシステムがアプローチを基礎づけた使用の利点は以下の通りです。
- It avoids fetching and storing of entire mapping tables by every
host that wishes to implement RFC1327 gateways and/or tools
- それはRFC1327ゲートウェイ、そして/または、ツールを実行したがっているすべてのホストによる全体のマッピングテーブルのとって来るのと格納を避けます。
- Modifications to the DNS based mapping information can be made
available in a more timely manner than with a table driven
approach.
- テーブルが動かされている状態でアプローチするよりタイムリーな方法で情報を写像しながら基づくDNSへの変更を利用可能にすることができます。
- It allows full authority delegation, in agreement with the
Internet regionalization process.
- それはインターネット領域化の過程に一致して完全な権威代表団を許容します。
Allocchio, Bonito, Cole, Giordano & Hagens [Page 3] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[3ページ]RFC1664インターネット
- Table management is not necessarily required for DNS-based
RFC1327 gateways.
- テーブル管理が必ずDNSベースのRFC1327ゲートウェイに必要であるというわけではありません。
- One can determine the mappings in use by a remote gateway by
querying the DNS (remote debugging).
- 人はリモートゲートウェイのそばでDNS(遠隔デバッギング)について質問することによって使用中のマッピングを決定できます。
Also many other tools, like address converters and User Agents can take advantage of the real-time availability of RFC1327 tables, allowing a much easier maintenance of the information.
他の多くのツールも、アドレスコンバータとUserのように、エージェントはRFC1327テーブルのリアルタイムの有用性を利用できます、情報のはるかに簡単な維持を許して。
3. The domain space for X.400 O/R name addresses
3. X.400O/R名前アドレスのためのドメインスペース
Usual domain names (the ones normally used as the global part of an RFC822 e-mail address) and their associated information, i.e., host IP addresses, mail exchanger names, etc., are stored in the DNS as a distributed database under a number of top-level domains. Some top- level domains are used for traditional categories or international organisations (EDU, COM, NET, ORG, INT, MIL...). On the other hand any country has its own two letter ISO country code as top-level domain (FR, DE, GB, IT, RU, ...), including "US" for USA. The special top-level/second-level couple IN-ADDR.ARPA is used to store the IP address to domain name relationship. Our proposal defines in the above structure the appropriate way to locate the X.400 O/R name space, thus enabling us to store in DNS the RFC1327 mapping data.
普通のドメイン名(通常、RFC822Eメールアドレスのグローバルな部分として使用されるもの)とそれらの関連情報、すなわち、ホストIPアドレス、メール交換器名などは分散データベースとしてDNSに多くの最上位のドメインの下で格納されます。 いくつかの先端の平らなドメインが伝統的なカテゴリか国際機関(EDU、COM、NET、ORG、INT、MIL…)に使用されます。 他方では、どんな国にも、最上位のドメイン(FR、DE GB、IT、RU)としてそれ自身の2手紙ISO国名略号があります、米国への「米国」を含んでいて。 第2特別なトップレベル/レベルカップルIN-ADDR.ARPAは、IPアドレスをドメイン名関係に格納するのに使用されます。 私たちの提案は上の構造でスペースというX.400O/R名の場所を見つける適切な方法を定義します、その結果、私たちがDNSにデータを写像するRFC1327を格納するのを可能にします。
The RFC1327 mapping information is composed by three tables: 'table1' gives the translation from X.400 to RFC822 while 'table2' and 'gate' tables map RFC822 into X.400. Each mapping table is composed by mapping rules, and a single mapping rule is composed by a keyword (the argument of the mapping function derived from the address to be translated) and a translator (the mapping function parameter):
RFC1327マッピング情報は3個のテーブルによって構成されます: 'table2'と'ゲート'テーブルはRFC822をX.400に写像しますが、'table1'はX.400からRFC822までの翻訳を与えます。 それぞれのマッピングテーブルは配置規則によって構成されます、そして、ただ一つの配置規則はキーワード(翻訳されるためにアドレスから得られたマッピング機能の議論)と翻訳者(マッピング機能パラメタ)によって構成されます:
keyword#translator#
キーワード#翻訳者#
the '#' sign is a delimiter enclosing the translator. An example:
'#'サインは翻訳者を同封するデリミタです。 例:
foo.bar.us#PRMD$foo\.bar.ADMD$intx.C$us#
foo.bar.us#PRMD$foo\.bar.ADMD$intx.C$、私たち、#
Local mappings are not intended for use outside their restricted environment, thus they should not be included in DNS. If local mappings are used, they should be stored using static local tables, exactly as local static host tables can be used with DNS.
使用のために彼らの制限された環境の外でローカルのマッピングを意図しません、その結果、DNSにそれらを含むべきではありません。 ローカルのマッピングが使用されているなら、それらは静的な地方のテーブルを使用することで格納されるべきです、ちょうどDNSと共に地方の静的なホストテーブルを使用できるように。
The keyword of a 'table2' and 'gate' table entry is a valid RFC822 domain; thus the usual domain name space can be used without problems to store these entries.
'table2'と'ゲート'テーブル項目に関するキーワードは有効なRFC822ドメインです。 したがって、これらのエントリーを格納するのに問題なしで普通のドメイン名スペースを使用できます。
Allocchio, Bonito, Cole, Giordano & Hagens [Page 4] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[4ページ]RFC1664インターネット
On the other hand, the keyword of a 'table1' entry belongs to the X.400 O/R name space. The X.400 O/R name space does not usually fit into the usual domain name space, although there are a number of similarities; a new name structure is thus needed to represent it. This new name structure contains the X.400 mail domains.
他方では、'table1'エントリーに関するキーワードはスペースというX.400O/R名に属します。 通常、スペースというX.400O/R名は普通のドメイン名スペースに収まりません、多くの類似性がありますが。 新しい名前構造が、それを表すのにこのようにして必要です。 この新しい名前構造はX.400メール・ドメインを含んでいます。
To ensure the correct functioning of the DNS system, the new X.400 name structure must be hooked to the existing domain name space in a way which respects the existing name hierarchy.
DNSシステムの正しい機能を確実にするために、階層構造という既存の名前を尊敬する方法で構造という新しいX.400名に既存のドメイン名スペースを接続しなければなりません。
A possible solution was to create another special branch, starting from the root of the DNS tree, somehow similar to the in-addr.arpa tree. This idea would have required to establish a central authority to coordinate at international level the management of each national X.400 name tree, including the X.400 public service providers. This coordination problem is a heavy burden if approached globally. More over the X.400 name structure is very 'country oriented': thus while it requires a coordination at national level, it does not have concepts like the international root. In fact the X.400 international service is based on a large number of bilateral agreements, and only within some communities an international coordination service exists.
可能な解決策は別の特別なブランチを創設することでした、DNS木の根から始めて、どうにかaddr.arpaの木と同様です。 X.400社会奉仕プロバイダーを含んでいて、この考えは、国際的なレベルでそれぞれの国家のX.400名前木の管理を調整する主要な権威を確立するのを必要としたでしょう。 グローバルにアプローチされるなら、この協調問題は重い負担です。 構造というX.400名の上の以上は非常に'国の指向しています': したがって、全国レベルでコーディネートを必要としている間、それには国際的な根のような概念がありません。 事実上、X.400の国際的なサービスは多くの二国間条約に基づいています、そして、いくつかの共同体だけの中では、国際協調サービスは存在しています。
The X.400 two letter ISO country codes, however, are the same used for the RFC822 country top-level domains and this gives us an appropriate hook to insert the new branches. Our proposal is, in fact, to create under each national top level ISO country code a new branch in the name space. This branch represents exactly the X.400 O/R name structure as defined in each single country, following the ADMD, PRMD, O, OU hierarchy. A unique reserved label 'X42D' is placed under each country top-level domain, and hence the national X.400 name space derives its own structure:
しかしながら、X.400two手紙ISO国名略号はRFC822国の最上位のドメインにおいて使用されていた状態で同じです、そして、これは新しいブランチを挿入するために適切なフックを私たちに与えます。 事実上、それぞれの国家の最高平らなISO国名略号の下で新しいブランチをスペースという名前で創設するために、私たちの提案はあります。 このブランチはそれぞれの単一の国で定義されるようにまさに構造というX.400O/R名を表します、ADMDに続いて、PRMD、O、OU階層構造。 ユニークな予約されたラベル'X42D'は各国最上位のドメインの下で置かれます、そして、したがって、スペースという国家のX.400名はそれ自身の構造を引き出します:
Allocchio, Bonito, Cole, Giordano & Hagens [Page 5] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[5ページ]RFC1664インターネット
. (root)
|
+-----------------+-----------+--------+-----------------+...
| | | |
edu it us fr
| | | |
+---+---+... +-----+-----+... +-----+-----+... +--+---+...
| | | | | | | | | |
... ... cnr X42D infn va ca X42D X42D inria
| | | |
+------------+------------+... ... ... +----+-------+...
| | | | |
ADMD-PtPostel ADMD-garr ADMD-Master400 ADMD-atlas ADMD-red
| | | |
+----------+----+... ... +-------+------+... ...
| | | |
PRMD-infn PRMD-STET PRMD-Telecom PRMD-Renault
| | | |
... ... ... ...
. (根)| +-----------------+-----------+--------+-----------------+... | | | | それをeduする、私たち、fr| | | | +---+---+... +-----+-----+... +-----+-----+... +--+---+... | | | | | | | | | | ... …cnr X42D infn va ca X42D X42D inria| | | | +------------+------------+... ... ... +----+-------+... | | | | | ADMD-PtPostel ADMD-garr ADMD-Master400 ADMD-地図帳ADMD-赤| | | | +----------+----+... ... +-------+------+... ... | | | | PRMD-テレコムPRMD-ルノーをPRMD-infn PRMD生きさせてください。| | | | ... ... ... ...
The creation of the X.400 new name tree at national level solves the problem of the international coordination. Actually the coordination problem is just moved at national level, but it thus becomes easier to solve. The coordination at national level between the X.400 communities and the Internet world is already a requirement for the creation of the national static RFC1327 mapping tables; the use of the Internet DNS gives further motivations for this coordination.
木という全国レベルにおけるX.400の新しい名の創造は国際協調の問題を解決します。 実際に協調問題は全国レベルでただ動かされますが、その結果、それは解決するのが、より簡単になります。 X.400共同体とインターネットの世界の間の全国レベルにおけるコーディネートは既にテーブルを写像する国家の静的なRFC1327の創造のための要件です。 インターネットDNSの使用はこのコーディネートに関するさらなる動機を与えます。
The coordination at national level also fits in the ongoing proposal intended to define exactly the RFC1327 Mapping Authorities. The DNS in fact allows a step by step authority distribution, up to a final complete delegation, which can be easily controlled at national level accordingly with national needs and situations. A further advantage of the national based solution is to allow each country to set up its own X.400 name structure in DNS and to deploy its own authority delegation according to its local time scale and requirements, with no loss of global service in the mean time. And last, placing the new X.400 name tree and coordination process at national level fits into the Internet regionalization and internationalisation process, as it requires local bodies to take care of local coordination problems.
また、全国レベルにおけるコーディネートはちょうどRFC1327 Mapping Authoritiesを定義することを意図する進行中の提案をうまくはめ込みます。 事実上、DNSは段階的な権威分配を許します、最終的な完全な代表団まで。(容易に、国家の必要性と状況で全国レベルでそれに従って、それを制御できます)。 国家のベースの解決策のさらなる利点は各国がDNSのそれ自身のX.400名前構造を設立して、その現地時間のスケールと要件に従ってその間にグローバルにサービスの損失なしでそれ自身の権威代表団を配備するのを許容することです。 そして、新しいX.400名前木とコーディネートの過程を全国レベルに置くと、最後にインターネット領域化と国際化の過程は収まります、地元調整問題の世話をするのが地方団体を必要とするとき。
The DNS name space thus contains completely the information required by an e-mail gateway or tool to perform the X.400-RFC822 mapping: a simple query to the nearest nameserver provides it. Moreover there is no more any need to store, maintain and distribute manually any mapping table. The new X.400 name space can also contain further information about the X.400 community, as DNS allows for it a
その結果、スペースというDNS名はメールゲートウェイかX.400-RFC822マッピングを実行するツールによって必要とされた情報を完全に含んでいます: 最も近いネームサーバへの簡単な質問はそれを提供します。 そのうえ、いいえは、より多くのいずれも手動でどんなマッピングテーブルも収納して、維持して、分配する必要があるあります。 また、DNSがそれのためにaを許容するとき、スペースという新しいX.400名はX.400共同体に関する詳細を含むことができます。
Allocchio, Bonito, Cole, Giordano & Hagens [Page 6] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[6ページ]RFC1664インターネット
complete set of resource records, and thus it allows further developments. This set of RRs in the new X.400 name space must be considered 'reserved' and thus not used until further specifications.
リソース記録のセットを完成してください。そうすれば、その結果、それはさらなる開発を許します。 スペースという新しいX.400名のRRsのこのセットを、'予約されている'と考えて、さらなる仕様までこのようにして使用してはいけません。
The construction of the new domain space trees will follow the same procedures used when organising at first the already existing DNS space: at first the information will be stored in a quite centralised way, and distribution of authority will be gradually achieved. A separate document will describe the implementation phase and the methods to assure a smooth introduction of the new service.
新しいドメインスペース木の工事は初めに既に既存のDNSスペースを構成しているとき用いられた同じ手順に従うでしょう: 初めに、情報はかなり集中化された方法で格納されるでしょう、そして、権限の分配は徐々に達成されるでしょう。 別々のドキュメントは実施フェーズと滑らかな序論に新しいサービスを保証する方法を説明するでしょう。
4. The new DNS resource record for RFC1327 mapping rules: PX
4. RFC1327配置規則のための新しいDNSリソース記録: PX
The specification of the Internet DNS (RFC1035) provides a number of specific resource records (RRs) to contain specific pieces of information. In particular they contain the Mail eXchanger (MX) RR and the host Address (A) records which are used by the Internet SMTP mailers. As we will store the RFC822 to X.400 mapping information in the already existing DNS name tree, we need to define a new DNS RR in order to avoid any possible clash or misuse of already existing data structures. The same new RR will also be used to store the mappings from X.400 to RFC822. More over the mapping information, i.e., the RFC1327 mapping rules, has a specific format and syntax which require an appropriate data structure and processing. A further advantage of defining a new RR is the ability to include flexibility for some eventual future development.
インターネットDNS(RFC1035)の仕様は、特定の情報を含むように、多くの特定のリソース記録(RRs)を提供します。 特に、それらはメールeXchanger(MX)RRとインターネットSMTP郵送者によって使用されるホストAddress(A)記録を含んでいます。 木という既に既存のDNS名にX.400マッピング情報にRFC822を格納するつもりであるとき、私たちは、既に既存のデータ構造のどんな可能な衝突や誤用も避けるために新しいDNS RRを定義する必要があります。 また、同じ新しいRRは、X.400からRFC822までマッピングを格納するのに使用されるでしょう。 マッピング情報の上の以上(すなわち、RFC1327配置規則)には、適切なデータ構造と処理を必要とする特定の形式と構文があります。 新しいRRを定義するさらなる利点は何らかの最後の今後の開発のための柔軟性を含む能力です。
The definition of the new 'PX' DNS resource record is:
新しい'PX'DNSリソース記録の定義は以下の通りです。
class: IN (Internet)
クラス: IN(インターネット)
name: PX (pointer to X.400/RFC822 mapping information)
以下を命名してください。 PX(X.400/RFC822マッピング情報へのポインタ)
value: 26
値: 26
The PX RDATA format is:
PX RDATA形式は以下の通りです。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MAP822 /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MAPX400 /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 好み| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MAP822 / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MAPX400 / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
どこ:
Allocchio, Bonito, Cole, Giordano & Hagens [Page 7] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[7ページ]RFC1664インターネット
PREFERENCE A 16 bit integer which specifies the preference given to
this RR among others at the same owner. Lower values
are preferred;
PREFERENCE A16は同じ所有者で特にこのRRに与えられた優先を指定する整数に噛み付きました。 下側の値は好まれます。
MAP822 A <domain-name> element containing <rfc822-domain>, the
RFC822 part of the RFC1327 mapping information;
<rfc822-ドメイン>、RFC1327マッピング情報のRFC822部分を含むMAP822A<ドメイン名>要素。
MAPX400 A <domain-name> element containing the value of
<x400-in-domain-syntax> derived from the X.400 part of
the RFC1327 mapping information (see sect. 4.2);
RFC1327マッピング情報のX.400部分から得られた中の<x400ドメイン構文>の値を含むMAPX400A<ドメイン名>要素(セクトを見てください。 4.2);
PX records cause no additional section processing. The PX RR format is the usual one:
PX記録はどんな追加セクション処理も引き起こしません。 PX RR形式は普通のものです:
<name> [<class>] [<TTL>] <type> <RDATA>
<名前>[<のクラス>][<TTL>]<タイプ><RDATA>。
When we store in DNS a 'table1' entry, then <name> will be an X.400 mail domain name in DNS syntax (see sect. 4.2). When we store a 'table2' or a 'gate' table entry, <name> will be an RFC822 mail domain name, including both fully qualified DNS domains and mail only domains (MX-only domains). All normal DNS conventions, like default values, wildcards, abbreviations and message compression, apply also for all the components of the PX RR. In particular <name>, MAP822 and MAPX400, as <domain-name> elements, must have the final "." (root) when they are fully qualified.
私たちがDNSに'table1'エントリーを格納すると、<名前>はDNS構文でX.400メールドメイン名になるでしょう。(セクトを見てください。 4.2). 私たちが'table2'か'ゲート'テーブル項目を格納するとき、<名前>は両方の完全に適切なDNSドメインを含むRFC822メールドメイン名であり、ドメイン(MXだけドメイン)だけを郵送するでしょう。 また、デフォルト値のようなすべての正常なDNSコンベンション(ワイルドカード、略語、およびメッセージ圧縮)が、PX RRのすべての部品に申し込みます。 「<名前>(<ドメイン名>要素としてのMAP822とMAPX400)には、特に、決勝がなければならない」、」 (根) それらは完全に資格があるとき。
4.1 Additional features of the PX resource record
4.1 PXリソース記録の追加特徴
The definition of the RDATA for the PX resource record, and the fact that DNS allows a distinction between an exact value and a wildcard match for the <name> parameter, represent an extension of the RFC1327 specification for mapping rules. In fact, any RFC1327 mapping table entry is an implicit wildcard entry, i.e., the rule
PXリソース記録のためのRDATAの定義、DNSが正確な値の区別を許容するという事実、および<名前>パラメタのためのワイルドカードマッチは配置規則のためのRFC1327仕様の拡大を表します。 事実上、すなわち、テーブル項目を写像するどんなRFC1327も暗黙のワイルドカードエントリー、規則です。
net2.it#PRMD$net2.ADMD$p400.C$it#
net2.it#PRMD$net2.ADMD$p400.C$、それ、#
covers any RFC822 domain ending with 'net2.it', unless more detailed rules for some subdomain in 'net2.it' are present. Thus there is no possibility to specify explicitly an RFC1327 entry as an exact match only rule. In DNS an entry like
'net2.it'の何らかのサブドメインのための、より詳細な規則が存在していない場合、'net2.it'でどんなRFC822ドメイン結末もカバーしています。 したがって、完全な一致が統治されるだけであるように明らかにRFC1327エントリーを指定する可能性が全くありません。 DNSのエントリーは好きです。
*.net2.it. IN PX 10 net2.it. PRMD-net2.ADMD-p400.C-it.
*.net2.it。 IN PX10net2.it。 PRMD-net2.ADMD-p400.C、-、それ
specify the usual wildcard match as for RFC1327 tables. However an entry like
RFC1327テーブルのように普通のワイルドカードマッチを指定してください。 しかしながら、エントリーは好きです。
ab.net2.it. IN PX 10 ab.net2.it. O-ab.PRMD-net2.ADMDb.C-it.
ab.net2.it。 IN PX10ab.net2.it。 O-ab.PRMD-net2.ADMDb.C、-、それ
Allocchio, Bonito, Cole, Giordano & Hagens [Page 8] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[8ページ]RFC1664インターネット
is valid only for an exact match of 'ab.net2.it' RFC822 domain.
'ab.net2.it'RFC822ドメインの完全な一致だけにおいて、有効です。
Note also that in DNS syntax there is no '#' delimiter around MAP822 and MAPX400 fields: the syntax defined in sect. 4.2 in fact does not allow the <blank> (ASCII decimal 32) character within these fields, making unneeded the use of an explicit delimiter as required in the RFC1327 original syntax.
また、そこのDNS構文によるそれがMAP822とMAPX400分野の周りの'#'デリミタでないことに注意してください: セクトで定義された構文。 4.2 事実上、必要に応じてRFC1327のオリジナルの構文で明白なデリミタの使用を不要にして、これらの分野の中に<の空白の>(ASCIIの10進32)にキャラクタを許容しません。
Another extension to the RFC1327 specifications is the PREFERENCE value defined as part of the PX RDATA section. This numeric value has exactly the same meaning than the similar one used for the MX RR. It is thus possible to specify more than one single mapping for a domain (both from RFC822 to X.400 and vice versa), giving as the preference order. In RFC1327 static tables, however, you cannot specify more than one mapping per each RFC822 domain, and the same restriction apply for any X.400 domain mapping to an RFC822 one.
RFC1327仕様への別の拡大はPX RDATA部の一部と定義されたPREFERENCE値です。 この数値には、まさに同じ意味がMX RRに使用される同様のものよりあります。 その結果、ドメインのための1つ以上のただ一つのマッピングを指定するのが可能である、(RFC822からX.400までの両方、逆もまた同様に)、好みの命令として、与えます。 しかしながら、RFC1327の静的なテーブルでは、あなたはそれぞれのRFC822ドメインあたり1つ以上のマッピングを指定できません、そして、同じ制限はどんなX.400ドメインマッピングにもRFC822 1に申し込みます。
More over, in the X.400 recommendations a note suggests than an ADMD=<blank> should be reserved for some special cases. Various national functional profile specifications for an X.400 MHS states that if an X.400 PRMD is reachable via any of its national ADMDs, independently of its actual single or multiple connectivity with them, it should use ADMD=<blank> to advertise this fact. Again, if a PRMD has no connections to any ADMD it should use ADMD=0 to notify its status, etc. However, in most of the current real situations, the ADMD service providers do not accept messages coming from their subscribers if they have a blank ADMD, forcing them to have their own ADMD value. In such a situation there are problems in indicating properly the actually working mappings for domains with multiple connectivity. The PX RDATA 'PREFERENCE' extension was introduced to take in consideration these problems.
X.400推薦では、注意は>がいくつかの特別なケースのために予約されるべきであるADMD=<空白より示されます。 X.400 PRMDがそれが彼らがいるその実際のシングルか複数の接続性の如何にかかわらずそうするべきである国家のADMDsのどれかを通して届くならADMDを使用するX.400 MHS州に、様々な国家の機能的なプロフィール仕様は、この事実の広告を出すために<の空白の>と等しいです。 一方、どんなADMDにもPRMDが接続が全くいないなら、それは状態などに通知するADMD=0を使用するべきです。 しかしながら、現在の現実の状況の大部分では、ADMDサービスプロバイダーは彼らが空白のADMDを持っているなら彼らの加入者から来るメッセージを受け入れません、彼らにそれら自身のADMD値を持たせて。 そのような状況に、複数の接続性で適切にドメインのための実際に働くマッピングを示すのにおいて問題があります。 PX RDATA'PREFERENCE'拡張子は、考慮でこれらの問題を取るために紹介されました。
However, as these extensions are not available with RFC1327 static tables, it is strongly discouraged to use them when interworking with any table based gateway or application. The extensions were in fact introduced just to add more flexibility, like the PREFERENCE value, or they were already implicit in the DNS mechanism, like the wildcard specification. They should be used very carefully or just considered 'reserved for future use'. In particular, for current use, the PREFERENCE value in the PX record specification should be fixed to a value of 50, and only wildcard specifications should be used when specifying <name> values.
しかしながら、これらの拡大がRFC1327の静的なテーブルで利用可能でないときに、それは、ベースのどんなテーブルでもゲートウェイを織り込むか、アプリケーションであるときに、それらを使用して、強くがっかりしています。 事実上、ただPREFERENCE値のような、より多くの柔軟性を加えるために拡大を導入したか、またはDNSメカニズムで既にそれらについて暗に示していました、ワイルドカード仕様のように。 それらは非常に慎重に使用されるか、またはただ考えられて'今後の使用のために予約されて'ことであるべきです。 現在の使用において、特に、PXの記録的な仕様によるPREFERENCE値は50の値に固定されるべきです、そして、<名前>値を指定するとき、ワイルドカード仕様だけが使用されるべきです。
4.2 The DNS syntax for an X.400 'domain'
4.2 X.400'ドメイン'へのDNS構文
The syntax definition of the RFC1327 mapping rules is defined in appendix F of that document. However that syntax is not very human oriented and contains a number of characters which have a special
RFC1327配置規則の構文定義はそのドキュメントの付録Fで定義されます。 しかしながら、その構文は、それほど指向していた状態で人間でなく、特別番組を持っている多くのキャラクタを含んでいます。
Allocchio, Bonito, Cole, Giordano & Hagens [Page 9] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[9ページ]RFC1664インターネット
meaning in other fields of the Internet DNS. Thus in order to avoid any possible problem, especially due to some old DNS implementations still being used in the Internet, we define a syntax for the X.400 part of any RFC1327 mapping rules (and hence for any X.400 O/R name) which makes it compatible with a <domain-name> element, i.e.,
インターネットの他の分野では、DNSを意味します。 したがって、私たちが特にインターネットでまだ使用されているいくつかの古いDNS実現のためどんな起こりうる問題も避けるためにどんなRFC1327配置規則のX.400部分とも構文を定義する、(どんなX.400O/R名も) したがって、すなわちそれを<ドメイン名>要素と互換性があるようにするどれ?
<domain-name> ::= <subdomain> | " "
<subdomain> ::= <label> | <label> "." <subdomain>
<label> ::= <alphanum>|
<alphanum> {<alphanumhyphen>} <alphanum>
<alphanum> ::= "0".."9" | "A".."Z" | "a".."z"
<alphanumhyphen> ::= "0".."9" | "A".."Z" | "a".."z" | "-"
<ドメイン名>:、:= <サブドメイン>。| 「「<サブドメイン>:、:、」= <ラベル>。| 「<ラベル>」、」 <サブドメイン><ラベル>:、:= <alphanum>| <alphanum><がalphanumする<alphanum><alphanumhyphen>、>:、:= "0".."9" | 「「A」。」「Z」| ""a""。「z」<alphanumhyphen>:、:= "0".."9" | 「「A」。」「Z」| ""a""。「z」| "-"
(see RFC1035, section 2.3.1, page 8). The legal character set for <label> does not correspond to the IA5 Printablestring one used in RFC1327 to define mapping rules. However a very simple "escape mechanism" can be applied in order to bypass the problem. We can in fact simply describe the X.400 part of an RFC1327 mapping rule format as:
(RFC1035、セクション2.3.1、8ページを参照します。) <ラベル>のための法的な文字の組は配置規則を定義するのにRFC1327で使用されるIA5 Printablestring1に対応していません。 しかしながら、問題を迂回させるために非常に簡単な「逃避機制」を適用できます。 事実上、私たちは、RFC1327配置規則形式のX.400一部分を単に以下と説明できます。
<map-rule> ::= <map-elem> | <map-elem> { "." <map-elem> }
<map-elem> ::= <attr-label> "$" <attr-value>
<attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU"
<attr-value> ::= " " | "@" | IA5-Printablestring
<地図規則>:、:= elemを写像している<>。| elemを写像している<>、「. 」 elemを写像している<>、elemを写像している<>:、:= <attr-ラベル>「$」<attr-価値の><attr-ラベル>:、:= 「C」| "ADMD"| "PRMD"| 「○」| "OU"<attr-価値の>:、:= " " | "@" | IA5-Printablestring
As you can notice <domain-name> and <map-rule> look similar, and also <label> and <map-elem> look the same. If we define the correct method to transform a <map-elem> into a <label> and vice versa the problem to write an RFC1327 mapping rule in <domain-name> syntax is solved.
<ドメイン名>と<地図規則>に気付くことができるように、同様に見えてください。そうすれば、また、<ラベル>とelemを写像している<>は同じくらい見ます。 私たちが逆もまた同様にelemを写像している<>を<ラベル>に変える正しい方法を定義するなら、<ドメイン名>構文でRFC1327配置規則を書く問題は解決されています。
The RFC822 domain part of any RFC1327 mapping rule is of course already in <domain-name> syntax, and thus remains unchanged.
どんなRFC1327配置規則のRFC822ドメイン部分ももちろんその結果、<ドメイン名>構文、および残りの中で既に変わりがありません。
In particular, in a 'table1' mapping rule the 'keyword' value must be converted into <x400-in-domain-syntax> (X.400 mail DNS mail domain), while the 'translator' value is already a valid RFC822 domain. Vice versa in a 'table2' or 'gate' mapping rule, the 'translator' must be converted into <x400-in-domain-syntax>, while the 'keyword' is already a valid RFC822 domain.
'table1'配置規則では、特に、中の<x400ドメイン構文>(X.400メールDNSメール・ドメイン)に'キーワード'値を変換しなければなりません、'翻訳者'値は既に有効なRFC822ドメインですが。 'table2'か'ゲート'配置規則で逆もまた同様です、中の<x400ドメイン構文>に'翻訳者'を変換しなければなりません、'キーワード'は既に有効なRFC822ドメインですが。
4.2.1 IA5-Printablestring to <alphanumhyphen> mappings
4.2.1 <alphanumhyphen>マッピングへのIA5-Printablestring
The problem of unmatching IA5-Printablestring and <label> character set definition is solved by a simple character mapping rule: whenever an IA5 character does not belong to <alphanumhyphen>, then it is mapped using its 3 digit decimal ASCII code, enclosed in hyphens. A small set of special rules is also defined for the most frequent cases. Moreover some frequent characters combinations used in RFC1327
unmatching IA5-Printablestringと<ラベル>文字の組定義の問題は簡単なキャラクタ配置規則によって解決されています: そして、IA5キャラクタが<alphanumhyphen>に属さないときはいつも、それは、ハイフンで同封された3ケタ小数ASCIIコードを使用することで写像されます。 また、小さいセットの特別な規則は最も頻繁なケースのために定義されます。 そのうえ、或るものはRFC1327で使用されるキャラクタ組み合わせによく行きます。
Allocchio, Bonito, Cole, Giordano & Hagens [Page 10] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[10ページ]RFC1664インターネット
rules are also mapped as special cases.
また、規則は特別なケースとして写像されます。
Let's then define the following simple rules:
次に、以下の簡単な規則を定義しましょう:
RFC1327 rule DNS store translation conditions
-----------------------------------------------------------------
<attr-label>$@ <attr-label> missing attribute
<attr-label>$<blank> <attr-label>"b" blank attribute
<attr-label>$xxx <attr-label>-xxx elsewhere
RFC1327規則DNSは翻訳状態を格納します。----------------------------------------------------------------- <attr-label>$@ <attr-label> missing attribute <attr-label>$<blank> <attr-label>"b" blank attribute <attr-label>$xxx <attr-label>-xxx elsewhere
Non <alphanumhyphen> characters in <attr-value>:
<attr-価値の>の非<のalphanumhyphen>キャラクタ:
RFC1327 rule DNS store translation conditions
-----------------------------------------------------------------
- -h- hyphen
\. -d- quoted dot
<blank> -b- blank
<non A/N character> -<3digit-decimal>- elsewhere
RFC1327規則DNSは翻訳状態を格納します。----------------------------------------------------------------- - -hハイフン\-dで引用されたドット<はほかの場所の>-b空白の<非A/Nキャラクタ><3digit10進の>が空白です。
If the DNS store translation of <attr-value> happens to end with an hyphen, then this last hyphen is omitted.
<attr-価値の>に関するDNS店翻訳がハイフンでたまたま終わるなら、この最後のハイフンは省略されます。
Let's now have some examples:
現在、いくつかの例を持ちましょう:
RFC1327 rule DNS store translation conditions
-----------------------------------------------------------------
PRMD$@ PRMD missing attribute
ADMD$<blank> ADMDb blank attribute
ADMD$400-net ADMD-400-h-net hyphen mapping
PRMD$UK\.BD PRMD-UK-d-BD quoted dot mapping
O$ACME Inc\. O-ACME-b-Inc-d blank & final hyphen
PRMD$main-400-a PRMD-main-h-400-h-a hyphen mapping
O$-123-b O--h-123-h-b hyphen mapping
OU$123-x OU-123-h-x hyphen mapping
PRMD$Adis+co PRMD-Adis-043-co 3digit mapping
RFC1327規則DNSは翻訳状態を格納します。----------------------------------------------------------------- PRMD$@ PRMD missing attribute ADMD$<blank> ADMDb blank attribute ADMD$400-net ADMD-400-h-net hyphen mapping PRMD$UK\.BD PRMD-UK-d-BD quoted dot mapping O$ACME Inc\. O-ACME-b-Inc-d blank & final hyphen PRMD$main-400-a PRMD-main-h-400-h-a hyphen mapping O$-123-b O--h-123-h-b hyphen mapping OU$123-x OU-123-h-x hyphen mapping PRMD$Adis+co PRMD-Adis-043-co 3digit mapping
Thus, an X.400 part from an RFC1327 mapping rule like
したがって、RFC1327配置規則からのX.400部分は好きです。
OU$uuu.O$@.PRMD$ppp\.rrr.ADMD$aaa ddd-mmm.C$cc
OU$uuu.O$@.PRMD$ppp \.rrr.ADMD$aaa ddd-mmm.C$cc
translates to
翻訳します。
OU-uuu.O.PRMD-ppp-d-rrr.ADMD-aaa-b-ddd-h-mmm.C-cc
OU-uuu.O. PRMD ppp d-rrr.ADMD-aaa-b-ddd-h-mmm.C cc
Another example:
別の例:
OU$sales dept\..O$@.PRMD$ACME.ADMD$ .C$GB
OU$販売dept\。 O$@.PRMD$ACME.ADMD$ .C$GB
Allocchio, Bonito, Cole, Giordano & Hagens [Page 11] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[11ページ]RFC1664インターネット
translates to
翻訳します。
OU-sales-b-dept-d.O.PRMD-ACME.ADMDb.C-GB
OU-販売b-dept-d.O.PRMD-ACME.ADMDb.C、-、GB
4.2.2 Flow chart
4.2.2 フローチャート
In order to achieve the proper DNS store translations of the X.400 part of an RFC1327 mapping rules or any other X.400 O/R name, some software tools will be used. It is in fact evident that the above rules for converting mapping table from RFC1327 to DNS format (and vice versa) are not user friendly enough to think of a human made conversion.
RFC1327配置規則のX.400部分かいかなる他のX.400O/R名の適切なDNS店翻訳も達成するために、いくつかのソフトウェアツールが使用されるでしょう。 事実上、RFC1327からDNS形式までテーブルを写像しながら変換するための上の規則が(逆もまた同様に)人間人工の変換を考えるくらいにはユーザフレンドリーでないことは、明白です。
To help in designing such tools, we describe hereunder a small flow chart. The fundamental rule to be applied during translation is, however, the following:
そのようなツールを設計するのを手伝うために、私たちは以下に小さいフローチャートを説明します。 しかしながら、翻訳の間に適用されるべき原理は以下です:
"A string must be parsed from left to right, moving appropriately
the pointer in order not to consider again the already translated
left section of the string in subsequent analysis."
「左から右まで五弦を分析しなければなりません、その後の分析で既に翻訳されているのが、ストリングの左のセクションであると再び考えない命令で適切にポインタを動かして。」
Flow chart 1 - Translation from RFC1327 to DNS format:
フローチャート1--RFC1327からDNSまでの翻訳は以下をフォーマットします。
parse single attribute
(enclosed in "." separators)
|
(yes) --- <label>$@ ? --- (no)
| |
map to <label> (no) <label>$<blank> ? (yes)
| | |
| map to <label>- map to <label>"b"
| | |
| map "\." to -d- |
| | |
| map "-" to -h- |
| | |
| map non A/N char to -<3digit>- |
restart | | |
^ | remove (if any) last "-" |
| | | |
| \-------> add a "." <--------------/
| |
\---------- take next attribute (if any)
「ただ一つの属性(」 . 」 分離符では、同封される)を分析してください。| (はい) --- <label>$@ ? --- (いいえ) | | <ラベル>$でないことの<の空白の>(はい)?<ラベル>に写像してください。| | | | <ラベル>「b」への<ラベル>-地図への地図| | | | dへの「」 \を写像してください。」、-| | | | | 「-」をhに写像してください、-| | | | | 非A/N炭を<3digit>に写像してください、-| 再開| | | ^ | 最後の「-」を取り除いてください(もしあれば)。| | | | | | \-------「>はa」を加えます。」 <、-、-、-、-、-、-、-、-、-、-、-、-、--/ | | \---------- 次の属性を取ってください。(もしあれば)
Allocchio, Bonito, Cole, Giordano & Hagens [Page 12] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[12ページ]RFC1664インターネット
Flow chart 2 - Translation from DNS to RFC1327 format:
フローチャート2--DNSからRFC1327までの翻訳は以下をフォーマットします。
parse single attribute
(enclosed in "." separators)
|
(yes) ---- <label> ? ---- (no)
| |
map to <label>$@ (no) <label>"b" ? (yes)
| | |
| map to <label>$ map to <label>$<blank>
| | |
| map -d- to "\." |
| | |
| map -h- to "-" |
| | |
| map -b- to " " |
restart | | |
^ | map -<3digit>- to non A/N char |
| | | |
| \--------> add a "." <----------/
| |
\------------- take next attribute (if any)
「ただ一つの属性(」 . 」 分離符では、同封される)を分析してください。| (はい) ---- <ラベル>?---- (いいえ) | | map to <label>$@ (no) <label>"b" ? (yes) | | | | <ラベル>$の<の空白の>への<ラベル>$地図への地図| | | | 「地図d、-、」 \に」| | | | | 地図h、-、「-」| | | | | 地図b、-、「」| 再開| | | ^ | <を写像している3digit>、-非A/Nに、焦げてください。| | | | | | \--------「>はa」を加えます。」 <、-、-、-、-、-、-、-、-、--/ | | \------------- 次の属性を取ってください。(もしあれば)
Note that the above flow charts deal with the translation of the attributes syntax, only.
上のフローチャートが属性構文だけに関する翻訳に対処することに注意してください。
4.2.3 The Country Code convention in the <name> value.
4.2.3 <名前>価値におけるCountry Codeコンベンション。
The RFC822 domain space and the X.400 O/R address space, as said in section 3, have one specific common feature: the X.400 ISO country codes are the same as the RFC822 ISO top level domains for countries. In the previous sections we have also defined a method to write in <domain-name> syntax any X.400 domain, while in section 3 we described the new name space starting at each country top level domain under the X42D.cc (where 'cc' is then two letter ISO country code).
RFC822ドメインスペースとX.400O/Rアドレス空間には、セクション3で言われているように、1つの特定の共通点があります: X.400 ISO国名略号はRFC822 ISOが平らなドメインを国に上回っているのと同じです。 また、前項で、私たちは<ドメイン名>構文でどんなX.400ドメインも書く方法を定義しました、私たちがセクション3でスペースというX42D.cc(次に'cc'が2手紙ISO国名略号であるところ)の下の各国トップ・レベル・ドメインで始まる新しい名前について説明しましたが。
The <name> value for a 'table1' entry in DNS should thus be derived from the X.400 domain value, translated to <domain-name> syntax, adding the 'X42D.cc.' post-fix to it, i.e.,
その結果、すなわち、DNSの'table1'エントリーへの<名前>価値は. <ドメイン名>構文に翻訳されたX.400ドメイン価値から得られて、'X42D.cc'を加えるのが、それへのポストフィックスであるならそうするでしょうに。
ADMD$acme.C$fr
ADMD$acme.C$fr
produces in <domain-name> syntax the key:
<ドメイン名>構文で、キーを生産します:
ADMD-acme.C-fr
ADMD-acme.C-fr
Allocchio, Bonito, Cole, Giordano & Hagens [Page 13] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[13ページ]RFC1664インターネット
which is post-fixed by 'X42D.fr.' resulting in:
どれが'X42D. fr'以下への結果になることで語尾に添えられていますか?
ADMD-acme.C-fr.X42D.fr.
ADMD-acme.C-fr.X42D. fr。
However, due to the identical encoding for X.400 country codes and RFC822 country top level domains, the string 'C-fr.X42D.fr.' is clearly redundant.
しかしながら、X.400国名略号とRFC822国の先端のための同じコード化がドメイン、ストリング'C-fr.X42D. fr'を平らにするか、明確に余分です。
We thus define the 'Country Code convention' for the <name> key, i.e.,
その結果、すなわち、私たちは主要であるという<名の>のために'国のCodeコンベンション'を定義します。
"The C-cc section of an X.400 domain in <domain-name> syntax must
be omitted when creating a <name> key, as it is identical to the
top level country code used to identify the DNS zone where the
information is stored".
「<名前>キーを作成するとき、<ドメイン名>構文によるX.400ドメインのC-cc部を省略しなければなりません、それが情報が格納されるDNSゾーンを特定するのに使用される最高平らな国名略号と同じであるときに。」
Thus we obtain the following <name> key examples:
したがって、私たちは以下の<名前>重要例を得ます:
X.400 domain DNS <name> key -------------------------------------------------------------------- ADMD$acme.C$fr ADMD-acme.X42D.fr. PRMD$ux\.av.ADMD$ .C$gb PRMD-ux-d-av.ADMDb.X42D.gb. PRMD$ppb.ADMD$Dat 400.C$de PRMD-ppb.ADMD-Dat-b-400.X42D.de.
X.400ドメインDNS<名前>キー-------------------------------------------------------------------- ADMD$acme.C$fr ADMD-acme.X42D. fr。 PRMD$ux\.av.ADMD$.C$gb PRMD-ux-d-av.ADMDb.X42D. gb。 PRMD$ppb.ADMD$Dat 400.C$de PRMD-ppb.ADMD-Dat-b-400.X42D. de。
4.3 Creating the appropriate DNS files
4.3 適切なDNSファイルを作成すること。
Using RFC1327's assumption of an asymmetric mapping between X.400 and RFC822 addresses, two separate relations are required to store the mapping database: RFC1327 'table1' and RFC1327 'table2'; thus also in DNS we will maintain the two different sections, even if they will both use the PX resource record. More over RFC1327 also specify a third table: RFC1327 'gate' Table. This additional table, however, has the same syntax rules than RFC1327 'table2' and thus the same translation procedure as 'table2' will be applied; some details about the RFC1327 'gate' table are discussed in section 4.4.
RFC1327のX.400とRFC822アドレスの間の非対称のマッピングの仮定を使用して、2つの別々の関係がマッピングデータベースを格納するのに必要です: RFC1327'table1'とRFC1327'table2'。 したがって、DNSでも、私たちは2の別区を維持するつもりです、ともにPXリソース記録を使用しても。 また、RFC1327の上の以上は第3のテーブルを指定します: RFC1327'ゲート'テーブル。 しかしながら、この追加テーブルには、同じシンタックス・ルールがRFC1327'table2'よりあります、そして、その結果、'table2'と同じ翻訳手順は適用されるでしょう。 セクション4.4でRFC1327'ゲート'テーブルに関するいくつかの詳細について議論します。
Let's now check how to create, from an RFC1327 mapping rule entry, the appropriate DNS entry in a DNS data file. We can again define an RFC1327 mapping rule entry as defined in appendix F of that document as:
現在、RFC1327配置規則エントリーからDNSデータファイルにおける適切なDNSエントリーを作成する方法をチェックしましょう。 私たちは再びそのドキュメントの付録Fで定義されるRFC1327配置規則エントリーを以下と定義できます。
<x400-domain>#<rfc822-domain># (case A: 'table1' entry)
<x400-ドメイン>#<rfc822-ドメイン>#(ケースA:'table1'エントリー)
and
そして
<rfc822-domain>#<x400-domain># (case B: 'table2' and 'gate' entry)
<rfc822-ドメイン>#<x400-ドメイン>#(ケースB: 'table2'と'ゲート'エントリー)
The two cases must be considered separately. Let's consider case A.
別々に2つのケースを考えなければなりません。 ケースAを考えましょう。
Allocchio, Bonito, Cole, Giordano & Hagens [Page 14] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[14ページ]RFC1664インターネット
- take <x400-domain> and translate it into <domain-name> syntax,
obtaining <x400-in-domain-syntax>;
- create the <name> key from <x400-in-domain-syntax> i.e., apply
the Country Code convention described in sect. 4.2.3;
- construct the DNS PX record as:
- <x400-ドメイン>を連れて行ってください、そして、中の<x400ドメイン構文>を入手して、<ドメイン名>構文にそれを翻訳してください。 - >という中の<x400ドメイン構文>から主要な<名を作成してください、そして、すなわち、セクトで説明されたCountry Codeコンベンションを適用してください。 4.2.3; - 以下としてDNS PX記録を構成してください。
*.<name> IN PX 50 <rfc822-domain> <x400-in-domain-syntax>
*. PX50<rfc822-ドメイン中の><x400ドメイン構文>による<名前>。
Please note that within PX RDATA the <rfc822-domain> precedes the <x400-in-domain-syntax> also for a 'table1' entry.
PX RDATAの中では、<rfc822-ドメイン>は'table1'エントリーにも中の<x400ドメイン構文>に先行します。
an example: from the rule
例: 規則から
PRMD$ab.ADMD$ac.C$fr#ab.fr#
PRMD$ab.ADMD$ac.C$fr#ab.fr#
we obtain
私たちは得ます。
*.PRMD-ab.ADMD-ac.X42D.fr. IN PX 50 ab.fr. PRMD-ab.ADMD-ac.C-fr.
*.PRMD-ab.ADMD-ac.X42D. fr。 IN PX50ab.fr。 PRMD-ab.ADMD-ac.C-fr。
Note that <name>, <rfc822-domain> and <x400-in-domain-syntax> are fully qualified <domain-name> elements, thus ending with a ".".
「<名前>、<rfc822-ドメイン>、および中の<x400ドメイン構文>が完全に適切な<ドメイン名>要素であることに注意して、その結果、a」で終わってください。」
Let's now consider case B.
現在、ケースBを考えましょう。
- take <rfc822-domain> as <name> key;
- translate <x400-domain> into <x400-in-domain-syntax>;
- construct the DNS PX record as:
- <名前>キーとして<rfc822-ドメイン>をみなしてください。 - 中の<x400ドメイン構文>に<x400-ドメイン>を翻訳してください。 - 以下としてDNS PX記録を構成してください。
*.<name> IN PX 50 <rfc822-domain> <x400-in-domain-syntax>
*. PX50<rfc822-ドメイン中の><x400ドメイン構文>による<名前>。
an example: from the rule
例: 規則から
ab.fr#PRMD$ab.ADMD$ac.C$fr#
ab.fr#PRMD$ab.ADMD$ac.C$fr#
we obtain
私たちは得ます。
*.ab.fr. IN PX 50 ab.fr. PRMD-ab.ADMD-ac.C-fr.
*.ab.fr。 IN PX50ab.fr。 PRMD-ab.ADMD-ac.C-fr。
Again note the fully qualified <domain-name> elements.
もう一度完全に適切な<ドメイン名>要素に注意してください。
Allocchio, Bonito, Cole, Giordano & Hagens [Page 15] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[15ページ]RFC1664インターネット
A file containing the RFC1327 mapping rules and RFC1327 'gate' table written in DNS format will look like the following fictious example:
DNS形式で書かれたRFC1327配置規則とRFC1327'ゲート'テーブルを入れてあるファイルは以下のfictiousの例に似るでしょう:
!
! RFC1327 table 1: X.400 --> RFC822
!
*.ADMD-acme.X42D.it. IN PX 50 it. ADMD-acme.C-it.
*.PRMD-accred.ADMD-tx400.X42D.it. IN PX 50 \
accred.it. PRMD-accred.ADMD-tx400.C-it.
*.O-u-h-newcity.PRMD-x4net.ADMDb.X42D.it. IN PX 50 \
cs.ncty.it. O-u-h-newcity.PRMD-x4net.ADMDb.C-it.
!
! RFC1327 table 2: RFC822 --> X.400
!
*.nrc.it. IN PX 50 nrc.it. PRMD-nrc.ADMD-acme.C-it.
*.ninp.it. IN PX 50 ninp.it. O.PRMD-ninp.ADMD-acme.C-it.
*.bd.it. IN PX 50 bd.it. PRMD-uk-d-bd.ADMDb.C-it.
!
! RFC1327 Gate Table
!
my.it. IN PX 50 my.it. OU-int-h-gw.O.PRMD-ninp.ADMD-acme.C-it.G.
co.it. IN PX 50 co.it. O-mhs-h-relay.PRMD-x4net.ADMDb.C-it.G.
RFC1327のテーブルの1: X.400-->RFC822!*.ADMD-acme.X42D.、それ。 IN PX、50 それ。 ADMD-acme.C、-、それ *.PRMD-accred.ADMD-tx400.X42D.、それ。 IN PXの50円のaccred.it。 PRMD-accred.ADMD-tx400.C、-、それ *.O-u-h-newcity.PRMD-x4net.ADMDb.X42D.、それ。 IN PXの50円のcs.ncty.it。 O-u-h-newcity.PRMD-x4net.ADMDb.C、-、それ ! ! RFC1327テーブル2: RFC822-->X.400!*.nrc.it。 IN PX50nrc.it。 PRMD-nrc.ADMD-acme.C、-、それ *.ninp.it。 IN PX50ninp.it。 O.PRMD-ninp.ADMD-acme.C、-、それ。 *.bd.it。 IN PX50bd.it。 PRMD-uk-d-bd.ADMDb.C、-、それ ! ! RFC1327 Gate Table!my.it。 IN PX50my.it。 OU-int-h-gw.O. PRMD-ninp.ADMD-acme.C-it.G. co.it。 IN PX50co.it。 O-mhs-h-relay.PRMD-x4net.ADMDb.C-it.G。
(here the "\" indicates continuation on the same line, as wrapping is done only due to typographical reasons).
(ここで、「\」は印刷の理由だけのためラッピングをするように同じ線の上に継続を示します。)
Note the special suffix ".G." on the right side of the 'gate' Table section whose aim is described in section 4.4. The corresponding RFC1327 tables are:
目的がセクション4.4で説明される'ゲート'テーブル部分の右側で特別な接尾語".G."に注意してください。 対応するRFC1327テーブルは以下の通りです。
#
# RFC1327 table 1: X.400 --> RFC822
#
ADMD$acme.C$it#it#
PRMD$accred.ADMD$tx400.C$it#accred.it#
O$u-newcity.PRMD$x4net.ADMD$ .C$it#cs.ncty.it#
#
# RFC1327 table 2: RFC822 --> X.400
#
nrc.it#PRMD$nrc.ADMD$acme.C$it#
ninp.it#O.PRMD$ninp.ADMD$acme.C$it#
bd.it#PRMD$uk\.bd.ADMD$ .C$it#
#
# RFC1327 Gate Table
#
my.it#OU$int-gw.O$@.PRMD$ninp.ADMD$acme.C$it#
co.it#O$mhs-relay.PRMD$x4net.ADMD$ .C$t#
# # RFC1327テーブル1: X.400--、>RFC822#ADMD$acme.C$、それ、#、それ、#PRMD$accred.ADMD$tx400.C$、それ、#accred.it#O$u-newcity.PRMD$x4net.ADMD$.C$、それ、#cs.ncty.it###RFC1327テーブル2: RFC822--、>X.400#nrc.it#PRMD$nrc.ADMD$acme.C$、それ、#ninp.it#O. PRMD$ninp.ADMD$acme.C$、それ、#bd.it#PRMD$uk\.bd.ADMD$.C$、それ、###RFC1327 Gate Table#my.it# OU$int-gw.O$@.PRMD$ninp.ADMD$acme.C$it #co.it#O$mhs-relay.PRMD$x4net.ADMD$.C$t#
Allocchio, Bonito, Cole, Giordano & Hagens [Page 16] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[16ページ]RFC1664インターネット
4.4 Storing the RFC1327 Gate table
4.4 RFC1327 Gateテーブルを収納すること。
Section 4.3.4 of RFC1327 also specify how an address should be converted between RFC822 and X.400 in case a complete mapping is impossible. To allow the use of DDAs for non mappable domains, the RFC1327 'gate' table is thus introduced. DNS must store and distribute also these data.
また、.4セクション4.3RFC1327が完全なマッピングが不可能であるといけないのでアドレスがRFC822とX.400の間でどう変換されるべきであるかを指定します。 DDAsの非mappableドメインの使用を許すために、RFC1327'ゲート'テーブルはこのようにして紹介されます。 また、DNSはこれらのデータを格納して、分配しなければなりません。
One of the major features of the DNS is the ability to distribute the authority: a certain site runs the "primary" nameserver for one determined sub-tree and thus it is also the only place allowed to update information regarding that sub-tree. This fact allows, in our case, a further additional feature to the table based approach. In fact we can avoid one possible ambiguity about the use of the 'gate' table (and thus of DDAs encoding).
DNSの主要な特徴の1つは権威を分配する能力です: ある一定のサイトは1つの決定している下位木のために「第一」のネームサーバを走らせます、そして、その結果、また、それはその下位木の情報をアップデートできた唯一の場所です。 この事実は私たちの場合でテーブルのベースのアプローチにさらなる付加的な機能を許容します。 事実上、私たちが'ゲート'テーブルの使用に関して1つの可能なあいまいさを避けることができる、(その結果、DDAsコード化、)
The authority maintaining a DNS entry in the usual RFC822 domain space is the only one allowed to decide if its domain should be mapped using Standard Attributes (SA) syntax or Domain Defined Attributes (DDA) one. If the authority decides that its RFC822 domain should be mapped using SA, then the PX RDATA will be a 'table2' entry, otherwise it will be a 'gate' table entry. Thus for an RFC822 domain we cannot have any more two possible entries, one from 'table2 and another one from 'gate' table, and the action for a gateway results clearly stated.
普通のRFC822ドメインスペースでDNSエントリーを維持する権威はドメインがStandard Attributes(SA)構文かDomain Defined Attributes(DDA)1を使用することで写像されるべきであるかどうか決めることができた唯一無二です。 権威が、RFC822ドメインがSAを使用することで写像されるべきであると決めるならPX RDATAが'table2'エントリーになる、さもなければ、それは'ゲート'テーブル項目になるでしょう。 したがって、RFC822ドメインに、私たちは''ゲート'テーブルからのtable2と別の1つ、および結果が明確に述べたゲートウェイのための動作'からのそれ以上の2つの可能なエントリー、1を持つことができません。
The RFC1327 'gate' table syntax is actually identical to RFC1327
'table2'. Thus the same syntax translation rules from RFC1327 to DNS
format can be applied. However a gateway or any other application
must know if the answer it got from DNS contains some 'table2' or
some 'gate' table information. This is easily obtained flagging with
an additional ".G." post-fix the PX RDATA value when it contains a
'gate' table entry. The example in section 4.3 shows clearly the
result. As any X.400 O/R domain must end with a country code ("C-xx"
in our DNS syntax) the additional ".G." creates no conflicts or
ambiguities at all. This postfix must obviously be removed before
using the RFC1327 'gate' table data.
RFC1327'ゲート'テーブルシンタックスは実際にRFC1327'table2'と同じです。 したがって、同じRFC1327からDNS形式までの構文翻訳規則を適用できます。 しかしながら、ゲートウェイかアプリケーションが、いかなる他のもそれがDNSから得た答えがいくつかの'table2'か何らかの'ゲート'テーブル情報を含むかどうかを知らなければなりません。 'ゲート'テーブル項目を含んでいると追加".G."ポストフィックスでPX RDATA値に旗を揚げさせながら、容易にこれを得ます。 セクション4.3の例は明確に結果を示しています。 どんなX.400O/Rドメインも国名略号(私たちのDNS構文による「C-xx」)で終わらなければならない間、追加".G."はどんな闘争もあいまいさも全く引き起こしません。 RFC1327'ゲート'テーブルデータを使用する前に、明らかにこのポストフィックスを取り除かなければなりません。
5. Finding RFC1327 mapping information from DNS
5. DNSからRFC1327がマッピング情報であることがわかります。
The RFC1327 mapping information is stored in DNS both in the normal RFC822 domain name space, and in the newly defined X.400 name space. The information, stored in PX resource records, does not represent a full RFC822 or X.400 O/R address: it is a template which specifies the fields of the domain that are used by the mapping algorithm.
RFC1327マッピング情報はDNSに正常なRFC822ドメイン名スペース、およびスペースという新たに定義されたX.400名で格納されます。 PXリソース記録に格納された情報は完全なRFC822かX.400O/Rアドレスを表しません: マッピングアルゴリズムで使用されるのは、ドメインの分野を指定するテンプレートです。
When mapping information is stored in the DNS, queries to the DNS are issued whenever an iterative search through the mapping table would
マッピング情報がDNSに格納されるとき、マッピングテーブルを通した繰り返しの検索が発行するだろうというときはいつも、DNSへの質問は発行されます。
Allocchio, Bonito, Cole, Giordano & Hagens [Page 17] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[17ページ]RFC1664インターネット
be performed (RFC1327: section 4.3.4, State I; section 4.3.5, mapping B). Due to the DNS search mechanism, DNS by itself returns the longest possible match in the stored mapping rule with a single query, thus no iteration and/or multiple queries are needed. As specified in RFC1327, a search of the mapping table will result in either success (mapping found) or failure (query failed, mapping not found).
実行されてください(RFC1327: セクション4.3.4、州I; Bを写像するセクション4.3.5)。 DNS検索メカニズムのため、それ自体でDNSはただ一つの質問と共に格納された配置規則における可能な限り長いマッチを返します、その結果、繰り返しでない、そして/または、複数の質問が必要です。 RFC1327で指定されるように、マッピングテーブルの検索は成功(見つけられたマッピング)か失敗のどちらかをもたらすでしょう(質問が失敗しました、とマッピングによって、わかりませんでした)。
When a DNS query is issued, a third possible result is timeout. If the result is timeout, the gateway operation is delayed and then retried at a later time. A result of success or failure is processed according to the algorithms specified in RFC1327. If a DNS error code is returned, an error message should be logged and the gateway operation is delayed as for timeout. These pathological situations, however, should be avoided with a careful duplication and chaching mechanism which DNS itself provides.
DNS質問が発行されるとき、3番目の可能な結果はタイムアウトです。 結果がタイムアウトであるなら、ゲートウェイ操作は、後で遅れて、次に、再試行されます。 RFC1327で指定されたアルゴリズムによると、成否の結果は処理されます。 DNSエラーコードが返されるなら、エラーメッセージは登録されるべきです、そして、ゲートウェイ操作はタイムアウトのように遅れます。 しかしながら、これらの病理学的な状況は、慎重な複製で避けられて、DNS自身が提供するメカニズムをchachingするべきです。
Searching the nameserver which can authoritatively solve the query is automatically performed by the DNS distributed name service.
厳然と質問を解決できるネームサーバを捜すのは分配された名前が調整するDNSによって自動的に実行されます。
5.1 A DNS query example
5.1 DNS質問の例
An RFC1327 mail-gateway located in the Internet, when translating addresses from RFC822 to X.400, can get information about the RFC1327 mapping rule asking the DNS. As an example, when translating the address SUN.CCE.NRC.IT, the gateway will just query DNS for the associated PX resource record. The DNS should contain a PX record like this:
RFC822からX.400までアドレスを翻訳するときインターネットに位置するRFC1327メール・ゲートウェイで、RFC1327配置規則の情報はDNSに尋ねることができます。 アドレスSUN. CCE.NRC.ITを翻訳するとき、例として、ゲートウェイは関連PXリソース記録のためにただDNSについて質問するでしょう。 DNSはこのようなPX記録を含むはずです:
*.cce.nrc.it. IN PX 50 cce.nrc.it. O-cce.PRMD-nrc.ADMD-acme.C-it.
*.cce.nrc.it。 IN PX50cce.nrc.it。 O-cce.PRMD-nrc.ADMD-acme.C、-、それ
The first query will return immediately the appropriate mapping rule in DNS store format.
最初の質問はすぐに、DNSの適切な配置規則に店形式を返すでしょう。
There is no ".G." at the end of the obtained PX RDATA value, thus applying the syntax translation specified in paragraph 4.2 the RFC1327 Table 2 mapping rule will be obtained.
その結果、".G."が全く得られたPX RDATA価値の終わりになくて、RFC1327テーブル2配置規則を得て、パラグラフ4.2で指定された構文翻訳を適用するでしょう。
Let's now take another example where a 'gate' table rule is returned. If we are looking for an RFC822 domain ending with top level domain "MW", and the DNS contains a PX record like this,
現在、'ゲート'テーブル規則が返される別の例を取りましょう。 私たちが先端があるRFC822ドメイン結末を探しているなら、ドメイン「MW」を平らにしてください。そうすれば、DNSはこのようなPX記録を含んでいます。
*.mw. IN PX 50 mw. O-cce.PRMD-nrc.ADMD-acme.C-it.G.
*.mw。 IN PX50mw。 O-cce.PRMD-nrc.ADMD-acme.C-it.G。
DNS will return 'mw.' and 'O-cce.PRMD-nrc.ADMD-acme.C-it.G.', i.e., a 'gate' table entry in DNS store format. Dropping the final ".G." and applying the syntax translation specified in paragraph 4.2 the original rule will be available. More over, the ".G." flag also tells
DNSは'mw''O-cce.PRMD-nrc.ADMD-acme.C-it.G.'、すなわち、DNS店形式における'ゲート'テーブル項目を返すでしょう。 最終的な".G."を落として、パラグラフ4.2で指定された構文翻訳を適用して、オリジナルの規則は利用可能になるでしょう。 また、".G."旗は、より言います。
Allocchio, Bonito, Cole, Giordano & Hagens [Page 18] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[18ページ]RFC1664インターネット
the gateway to use DDA encoding for the inquired RFC822 domain.
問い合わせられたRFC822ドメインのためのDDAコード化を使用するゲートウェイ。
On the other hand, translating from X.400 to RFC822 the address
他方では、X.400からRFC822までアドレスを翻訳します。
C=de; ADMD=pkz; PRMD=nfc; O=top;
Cはdeと等しいです。 ADMD=pkz。 PRMD=nfc。 Oは先端と等しいです。
the mail gateway should convert the syntax according to paragraph 4.2, apply the 'Country code convention' described in 4.2.3 to derive the appropriate DNS translation of the X.400 O/R name and then query DNS for the corresponding PX resource record. The obtained record for which the PX record must be queried is thus:
パラグラフ4.2によってメール・ゲートウェイが構文を変換するはずであり、中で説明された'国名略号コンベンション'を適用してください、4.2、.3、X.400O/R名の適切なDNS翻訳を引き出して、次に、対応するPXリソースのためにDNSについて質問するには、記録してください。 その結果、PX記録について質問しなければならない得られた記録は以下の通りです。
O-top.PRMD-nfc.ADMD-pkz.X42D.de.
O-top.PRMD-nfc.ADMD-pkz.X42D. de。
The DNS could contain:
DNSは以下を含むかもしれません。
*.ADMD-pkz.X42D.de. IN PX 50 pkz.de. ADMD-pkz.C-de.
*.ADMD-pkz.X42D. de。 IN PX50pkz.de。 ADMD-pkz.C-de。
Assuming that there are not more specific records in DNS, the wildcard mechanism will return the RFC1327 'table1' rule in encoded format.
より特定の記録がDNSにないと仮定すると、ワイルドカードメカニズムはコード化された形式でRFC1327'table1'規則を返すでしょう。
6. Administration of mapping information
6. マッピング情報の政権
The DNS, using the PX RR, will be able to distribute the mapping information to all RFC1327 gateways located on the Internet. However, not all RFC1327 gateways will be able to use the Internet DNS. It is expected that some gateways in a particular management domain will conform to one of the following models:
PX RRを使用して、DNSはインターネットに位置するすべてのRFC1327ゲートウェイにマッピング情報を分配できるでしょう。 しかしながら、すべてのRFC1327ゲートウェイがどんなインターネットDNSを使用できるというわけではないでしょう。 特定の管理ドメインの数門が以下のモデルのひとりに一致すると予想されます:
(a) Table-based, (b) DNS-based, (c) X.500-based
(a) テーブルベースである、(b)、DNSベースである、(c)、X.500ベース
Table-based management domains will continue to submit and retrieve their mapping tables from the International Mapping Table coordinator manually or via some automated procedures. Their mapping information should be made available in DNS by the appropriate DNS authority using the same mechanism already in place for MX records: if a branch has not yet in place its own DNS server, some higher authority in the DNS tree will provide the service for it. A transition procedure similar to the one used to migrate from the 'hosts.txt' tables to DNS can be applied also to the deployment phase of this proposal. An informational document describing the implementation phase and the detailed coordination procedures is expected. The deployment phase must also follow the directives produced by the current work on RFC1327 mapping authorities, in order to insure consistency in the mapping information itself.
テーブルベースの管理ドメインは、国際Mapping Tableコーディネータから手動かいくつかの自動化手順でテーブルを写像するのを提出して、検索し続けるでしょう。 適切なDNS権威はDNSでMX記録に適所で既に同じメカニズムを使用することでそれらのマッピング情報を利用可能にするべきです: ブランチが今まで適所でそうしていないなら、それ自身のDNSサーバ、DNS木の何らかのより高い権威がそれのためのサービスを提供するために望んでいます。 また、'hosts.txt'テーブルからDNSまで移動するのに使用されるものと同様の変遷手順をこの提案の展開フェーズに適用できます。 実施フェーズと詳細な協力手順を説明する情報のドキュメントは予想されます。 また、展開フェーズは当局を写像するRFC1327への執筆中の作品で起こされた指示に続かなければなりません、マッピング情報自体の一貫性を保障するために。
Allocchio, Bonito, Cole, Giordano & Hagens [Page 19] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[19ページ]RFC1664インターネット
Another distributed directory service which can distribute the RFC1327 mapping information is X.500. The coordination, alignment and uniqueness of mapping information between DNS and X.500 is an essential fact if it happens to have both systems in place. The ideal solution is a dynamic alignment mechanism which transparently makes the DNS mapping information available in X.500 and vice versa. Some work in this specific field is already being done [see Costa] which can result in a global transparent directory service, where the information is stored in DNS or in X.500, but is visible completely by any of the two systems.
RFC1327マッピング情報を分配できる別の分配された電話番号案内はX.500です。 適所に両方のシステムを持っているのが起こるなら、DNSとX.500の間のマッピング情報のコーディネート、整列、およびユニークさは基本的な事実です。 理想的な解決は透明に逆もまた同様にDNSをX.500で利用可能なマッピング情報にするダイナミックアライメントメカニズムです。 この特定の分野でのいくらかの仕事は既に情報がDNSに格納されるところかX.500でグローバルな透明な電話番号案内をもたらすことができますが、完全に2台のシステムのいずれでも目に見えるすることです[コスタを見ます]。
7. Conclusion
7. 結論
The introduction of the new PX resource record and the definition of the X.400 O/R name space in the DNS structure provide a good repository for mapping information. The mapping information is stored in the DNS tree structure so that it can be easily obtained using the DNS distributed name service. At the same time the definition of the appropriate DNS space for X.400 O/R names provide a repository where to store and distribute some other X.400 MHS information. The use of the DNS has many known advantages in storing, managing and updating the information. A successful number of tests have been performed under the provisional top level domain "X400.IT", and their results confirmed the advantages of the method.
新しいPXリソース記録の導入とDNS構造とのスペースというX.400O/R名の定義は良い倉庫をマッピング情報に提供します。 マッピング情報がDNS木構造に格納されるので、DNSを使用することで容易にそれを得ることができるのは名前サービスを広げました。 ある他のX.400 MHS情報をX.400O/Rのための適切なDNSスペースの定義が命名する同時に、どこを倉庫に供給するか、そして、格納して、分配してください。 DNSの使用は情報を格納して、管理して、アップデートする際に多くの知られている利点を持っています。 うまくいっている数のテストが暫定的なトップ・レベル・ドメイン"X400.IT"の下で実行されました、そして、それらの結果は方法の利点を確認しました。
Software to query the DNS and then to convert between the textual representation of DNS resource records and the address format defined in RFC1327 needs to be developed. This software must also allow a smooth implementation and deployment period, eventually taking care of the transition phase. A further informational document describing operational and implementation of the service is expected.
DNSについて質問して、そして、DNSリソース記録の原文の表現とRFC1327で定義されたアドレス形式の間で変換するソフトウェアは、開発される必要があります。 また、結局過渡期の世話をして、このソフトウェアは滑らかな実現と展開の期間を許容しなければなりません。 Aは操作上で情報のドキュメント説明を促進します、そして、サービスの実現は予想されます。
8. Acknowledgements
8. 承認
We wish to thanks all those who contributed to the discussion and revision of this document: many of their ideas and suggestions constitute essential parts of this work. In particular thanks to Jon Postel, Paul Mockapetris, Rob Austin and the whole IETF x400ops, RARE wg-msg and IETF namedroppers groups. A special mention to Christian Huitema for his fundamental contribution to this work.
私たちは感謝にこのドキュメントの議論と改正に貢献した人を願っています: 彼らの考えと提案の多くがこの仕事の不可欠の部分を構成します。 ジョン・ポステル、ポールMockapetris、ロブオースチン、全体のIETF x400ops、RARE wg-msg、およびIETF namedroppersグループを特にありがとうございます。 この仕事への彼の基本的貢献のためのクリスチャンのHuitemaへの特記。
Allocchio, Bonito, Cole, Giordano & Hagens [Page 20] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[20ページ]RFC1664インターネット
9. References
9. 参照
[CCITT] CCITT SG 5/VII, "Recommendation X.400, Message Handling
Systems: System Model - Service Elements", October 1988.
[CCITT] CCITT SG5/VII、「推薦X.400、メッセージハンドリングシステム:」 「システムモデル--Elementsにサービスを提供する」1988年10月。
[RFC 1327] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC
822", RFC 1327, March 1992.
Kille、[RFC1327]S.、「X.400(1988)/ISO10021とRFC822インチの間のマッピング、RFC1327、3月1992日
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, USC/Information Sciences Institute, November
1987.
Mockapetris、[RFC1034]P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、科学が設けるUSC/情報、11月1987日
[RFC 1035] Mockapetris, P., "Domain names - Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
Mockapetris、[RFC1035]P.、「ドメイン名--、実現とSpecification、」、STD13、RFC1035、USC/情報Sciences Institute、11月1987日
[RFC 1033] Lottor, M., "Domain Administrators Operation Guide", RFC
1033, SRI International, November 1987.
[RFC1033] Lottor、M.、「ドメイン管理者のオペレーション・ガイド」、RFC1033、SRIインターナショナル、1987年11月。
[Costa] Costa, A., Macedo, J., and V. Freitas, "Accessing and
Managing DNS Information in the X.500 Directory", Proceeding of
the 4th Joint European Networking Conference, Trondheim, NO, May
1993.
[コスタ]コスタ(A.、Macedo、J.、V.フレータス、「X.500ディレクトリでDNS情報にアクセスして、管理する」第4共同ヨーロッパのネットワークコンファレンスの進行、トロンヘイム、およびいいえ)は、1993がそうするかもしれません。
[Houttin] Houttin, J., Hansen, K., and S. Aumont, "Address Mapping
Functions and Authorities", Internet-DRAFT, May 1993.
[Houttin] Houttin、J.、ハンセン、K.、およびS.オーモン、「機能と当局を写像するアドレス」、インターネット草稿は1993がそうするかもしれません。
10. Security Considerations
10. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Allocchio, Bonito, Cole, Giordano & Hagens [Page 21] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[21ページ]RFC1664インターネット
11. Authors' Addresses
11. 作者のアドレス
Claudio Allocchio Sincrotrone Trieste Padriciano 99 I 34012 Trieste Italy
クラウディオAllocchio SincrotroneトリエステPadriciano99I34012トリエステイタリア
RFC822: Claudio.Allocchio@elettra.trieste.it X.400: C=it;A=garr;P=Trieste;O=Elettra; S=Allocchio;G=Claudio; Phone: +39 40 3758523 Fax: +39 40 226338
RFC822: Claudio.Allocchio@elettra.trieste.it X.400: C=それ; A=garr; Pはトリエステと等しいです; Oはエレットラと等しいです。 S=Allocchio; Gはクラウディオと等しいです。 以下に電話をしてください。 +39 40 3758523、Fax: +39 40 226338
Antonio Blasco Bonito CNUCE - CNR Reparto infr. reti Viale S. Maria 36 I 56126 Pisa Italy
アントニオBlasco Bonito CNUCE--CNR Reparto infr. retiビアール・S.マリア36I56126Pisaイタリア
RFC822: bonito@cnuce.cnr.it X.400: C=it;A=garr;P=cnr;O=cnuce;S=bonito; Phone: +39 50 593246 Fax: +39 50 589354
RFC822: bonito@cnuce.cnr.it X.400: C=それ; A=garr; P=cnr; O=cnuce; Sはかつおと等しいです。 以下に電話をしてください。 +39 50 593246、Fax: +39 50 589354
Bruce Cole Cisco Systems Inc. P.O. Box 3075 1525 O'Brien Drive Menlo Park, CA 94026 U.S.A.
ブルースコールシスコシステムズ株式会社P.O. Box3075 1525オブライエン・Driveカリフォルニア94026メンローパーク(米国)
RFC822: bcole@cisco.com X.400: C=us;A= ;P=Internet; DD.rfc-822=bcole(a)cisco.com; Phone: +1 415 6888245 Fax: +1 415 6884575
RFC822: bcole@cisco.com X.400: C=私たち; =; Pはインターネットと等しいです。 DD.rfc-822=bcole(a)cisco.com。 以下に電話をしてください。 +1 415 6888245Fax: +1 415 6884575
Allocchio, Bonito, Cole, Giordano & Hagens [Page 22] RFC 1664 Internet DNS for Mail Mapping Tables August 1994
メールマッピングのためのDNSが1994年8月に見送るAllocchio、かつお、コール、ジョルダーノ、およびHagens[22ページ]RFC1664インターネット
Silvia Giordano Centro Svizzero di Calcolo Scientifico Via Cantonale CH 6928 Manno Switzerland
シルビア・ジョルダーノ・セントロSvizzeroディCalcolo Scientifico Via Cantonale CH6928Mannoスイス
RFC822: giordano@cscs.ch X.400: C=ch;A=arcom;P=switch;O=cscs; S=giordano; Phone: +41 91 508213 Fax: +41 91 506711
RFC822: giordano@cscs.ch X.400: C=ch; A=arcom; Pはスイッチと等しいです; O=cscs S=giordano。 以下に電話をしてください。 +41 91 508213、Fax: +41 91 506711
Robert Hagens Advanced Network and Services 1875 Campus Commons Drive Reston, VA 22091 U.S.A.
ロバートHagensはネットワークとサービス1875キャンパス共有Driveヴァージニア22091レストン(米国)を唱えました。
RFC822: hagens@ans.net X.400: C=us;A= ;P=Internet; DD.rfc-822=hagens(a)ans.net; Phone: +1 703 7587700
RFC822: hagens@ans.net X.400: C=私たち; =; Pはインターネットと等しいです。 DD.rfc-822=hagens(a)ans.net。 以下に電話をしてください。 +1 703 7587700
Allocchio, Bonito, Cole, Giordano & Hagens [Page 23]
Allocchio、かつお、コール、ジョルダーノ、およびHagens[23ページ]
一覧
スポンサーリンク
