RFC2163 日本語訳
2163 Using the Internet DNS to Distribute MIXER Conformant GlobalAddress Mapping (MCGAM). C. Allocchio. January 1998. (Format: TXT=58789 bytes) (Obsoletes RFC1664) (Updated by RFC3597) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Allocchio Request for Comments: 2163 GARR-Italy Obsoletes: 1664 January 1998 Category: Standards Track
Allocchioがコメントのために要求するワーキンググループC.をネットワークでつないでください: 2163 ガー-イタリアは以下を時代遅れにします。 1664 1998年1月のカテゴリ: 標準化過程
Using the Internet DNS to Distribute
MIXER Conformant Global Address Mapping (MCGAM)
ミキサーConformantグローバルアドレスマッピングを分配するのにインターネットDNSを使用します。(MCGAM)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This memo is the complete technical specification to store in the Internet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant 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. Organizations can publish their MIXER mapping or preferred gateway routing information using just local resources (their local DNS server), avoiding the need for a strong coordination with any centralised organization. MIXER conformant gateways and tools 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.
このメモはマッピング情報(MCGAM)がMIXER conformantメールゲートウェイと他の道具でX.400O/R名にRFC822ドメイン名を写像する必要があったインターネットドメインネームシステム(DNS)に逆もまた同様に保存する完全な技術仕様書です。 集中化されているというよりむしろ分配された方法でマッピング情報に対処できます。 組織はまさしくローカル資源(地元のDNSサーバ)を使用することでそれらのMIXERマッピングか都合のよいゲートウェイルーティング情報を発表できます、どんな集中化された組織と共にも強いコーディネートの必要性を避けて。 インターネット・ホストの上に位置するMIXER conformantゲートウェイと道具は中心でアップデートして、分配する必要がある固定テーブルを持っていることの代わりにDNSについて質問するマッピング情報を検索できます。
This memo obsoletes RFC1664. It includes the changes introduced by MIXER specification with respect to RFC1327: the new 'gate1' (O/R addresses to domain) table is fully supported. Full backward compatibility with RFC1664 specification is mantained, too.
このメモはRFC1664を時代遅れにします。 それはRFC1327に関してMIXER仕様で導入された変化を含んでいます: 新しい'gate1'(ドメインへのO/Rアドレス)テーブルは完全に支えられます。 また、RFC1664仕様との完全な後方の互換性はmantainedされます。
RFC1664 was a joint effort of IETF X400 operation working group (x400ops) and TERENA (formely named "RARE") Mail and Messaging working group (WG-MSG). This update was performed by the IETF MIXER working group.
RFC1664は(x400ops)とTERENA(組版に「まれな」状態で命名される)が郵送するIETF X400操作ワーキンググループとメッセージング作業部会(WG-エムエスジー)の共同努力でした。 このアップデートはIETF MIXERワーキンググループによって実行されました。
Allocchio Standards Track [Page 1] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[1ページ]。
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と外国世界の両方のネイティブのものから区別できないアドレスをもたらして。
MIXER describes a set of mappings (MIXER Conformant Global Address Mapping - MCGAM) which will enable interworking between systems operating the CCITT X.400 (1984/88/92) Recommendations and systems using 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 MIXER: the mechanism for mapping between X.400 O/R addresses and RFC822 domain names. As described in Appendix F of MIXER, implementation of the mappings requires a database which maps between X.400 O/R addresses and domain names; in RFC1327 this database was statically defined.
MIXERはRFC822メールプロトコルを使用するか、またはRFC822から得られたプロトコルを使用することでCCITT X.400(1984/88/92)推薦を操作するシステムとシステムの間の織り込むことを可能にする1セットのマッピング(MIXER Conformant Global Address Mapping--MCGAM)について説明します。 そのドキュメントは2台のメールシステムの間のサービス、アドレス、メッセージ封筒、およびメッセージ本体の変換を扱います。このドキュメントはMIXERの1つの局面に関係があります: X.400O/RのアドレスとRFC822の間でドメイン名を写像するためのメカニズム。 MIXERのAppendix Fで説明されるように、マッピングの実装はX.400O/Rの間でアドレスとドメイン名を写像するデータベースを必要とします。 RFC1327では、このデータベースは静的に定義されました。
The original approach in RFC1327 required many efforts to maintain the correct mapping: all the gateways needed to get coherent tables to apply the same mappings, the conversion tables had to be distributed among all the operational gateways, and also every update needed to be distributed.
RFC1327でのオリジナルのアプローチは正しいマッピングを維持するために多くの取り組みを必要としました: すべてのゲートウェイが、一貫性を持っているテーブルに同じマッピングを適用させる必要がありました、そして、変換テーブルはすべての操作上のゲートウェイの中で分配されなければなりませんでした、そして、あらゆるアップデートも分配される必要がありました。
The concept of mapping rules distribution and use has been revised in the new MIXER specification, introducing the concept of MIXER Conformant Global Address Mapping (MCGAM). A MCGAM does not need to be globally installed by any MIXER conformant gateway in the world any more. However MIXER requires now efficient methods to publish its MCGAM.
配置規則分配と使用の概念は新しいMIXER仕様で改訂されました、MIXER Conformant Global Address Mapping(MCGAM)の概念を紹介して。 それ以上世界のどんなMIXER conformantゲートウェイによってもMCGAMによってグローバルにインストールされる必要はありません。 しかしながら、MIXERはMCGAMを発行する現在効率的なメソッドを必要とします。
Static tables are one of the possible methods to publish MCGAM. However 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.
静的なテーブルはMCGAMを発行する可能なメソッドの1つです。 しかしながら、この静止機構は情報を変更して、分配するのに費やされるべきかなり長い時間を必要とします、あらゆるアップデートの時間割に重い規制を置いて。 事実上、インターネットDomain Name Service(DNS)と比べて、それは効率的に見えません。 それの上の以上は他の多くの役に立つアプリケーションにデータベースを分配するのにおいて可能に見えません、ローカルアドレスコンバータ、メールUserエージェントまたは生産するために配置規則を必要とするいかなる他のツールも結果を修正するように。
Allocchio Standards Track [Page 2] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[2ページ]。
Two much more efficient methods are proposed by MIXER for publication of MCGAM: the Internet DNS and X.500. This memo is the complete technical specification for publishing MCGAM via Internet DNS.
2つのはるかに効率的なメソッドがMCGAMの公表のためにMIXERによって提案されます: インターネットDNSとX.500。 このメモは、インターネットDNSを通してMCGAMを発行するための完全な技術仕様書です。
A first proposal to use the Internet DNS to store, retrieve and maintain those mappings was introduced by two of the authors of RFC1664 (B. Cole and R. Hagens) adopting two new DNS resource record (RR) types: TO-X400 and TO-822. This proposal now adopts a more complete strategy, and requires one new RR only. The distribution of MCGAMs 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)タイプを採用しながら、RFC1664(B.コールとR.Hagens)の2人の作者によって紹介されました: X400と、そして、-822に。 この提案は、現在より完全な戦略を採用して、1新しいRRだけを必要とします。 事実上、DNSを通したMCGAMsの分配は全体のインターネットコミュニティのための大任です: それは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 deployed by some of the authors of RFC1664 at the time of its development. 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を使用することにおける最初の実験は開発時点で、RFC1664の何人かの作者によって配布されました。 既存の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
called 'gate2' 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 ('table1' and 'gate1'). A "two-way" mapping
resolution schema is thus fully implemented.
基本的な考え方はマッピング情報を保存するために新しいDNS RRを採用することです。 X.400配置規則(いわゆる'gate2'規則を含んでいる)へのRFC822は普通のDNS木に保存されるでしょう、それぞれの国家のトップ・レベル・ドメインの下で定義された名前スペースの新しいブランチの定義がRFC822マッピング('table1'と'gate1')に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 MCGAM syntax, showing how it can be stored into the Internet DNS.
この紙では、どうそれを保存できるかをインターネットDNSに招き入れて、私たちはMCGAM構文を採用するつもりです。
Allocchio Standards Track [Page 3] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[3ページ]。
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 MIXER gateways require that a database store address mapping information for X.400 and RFC822. This information must be made available (published) to all MIXER 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:
MIXERゲートウェイの実装は、データベースがX.400とRFC822のためのアドレスマッピング情報を保存するのを必要とします。 この情報をすべてのMIXERゲートウェイに利用可能に(発行されます)しなければなりません。 インターネットコミュニティでは、DNSは、分配された名前サービスを提供するための実用的な平均であると判明しました。 O/Rアドレスとドメイン名の間で写像されるテーブルの上のDNSのベースのシステムがアプローチを基礎づけた使用の利点は以下の通りです。
- It avoids fetching and storing of entire mapping tables by every
host that wishes to implement MIXER gateways and/or tools
- それはMIXERゲートウェイ、そして/または、ツールを実装したがっているすべてのホストによる全体のマッピングテーブルのとって来るのと保存を避けます。
- 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.
- それはインターネット領域化プロセスに合意して完全な権威委譲を許容します。
- Table management is not necessarily required for DNS-based
MIXER gateways.
- テーブル管理が必ずDNSベースのMIXERゲートウェイに必要であるというわけではありません。
- 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 MIXER tables, allowing a much easier maintenance of the information.
他の多くのツールも、アドレスコンバータとUserのように、エージェントはMIXERテーブルのリアルタイムの有用性を利用できます、情報のはるかに簡単なメインテナンスを許容して。
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
普通のドメイン名(通常、RFC822Eメールアドレスのグローバルな部分として使用されるもの)とそれらの関連情報、すなわち、ホストIPアドレス、メール交換器名などはaとしてDNSに保存されます。
Allocchio Standards Track [Page 4] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[4ページ]。
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. This memo defines in the above structure the appropriate way to locate the X.400 O/R name space, thus enabling to store in DNS the MIXER mappings (MCGAMs).
多くの最上位のドメインの下における分散データベース。 いくつかの先端の平らなドメインが伝統的なカテゴリか国際機関(EDU、COM、NET、ORG、INT、MIL…)に使用されます。 他方では、どんな国にも、最上位のドメイン(FR、DE GB、IT、RU)としてそれ自身の2手紙ISO国名略号があります、米国への「米国」を含んでいて。 第2特別なトップレベル/レベルカップルIN-ADDR.ARPAは、ドメイン名関係としてIPアドレスを保存するのに使用されます。 このメモは、DNSにMIXERマッピング(MCGAMs)を保存するために上の構造でその結果、スペースというX.400O/R名、可能にすることの場所を見つける適切な方法を定義します。
The MIXER mapping information is composed by four tables:
MIXERマッピング情報は4個のテーブルによって構成されます:
- 'table1' and 'gate1' gives the translation from X.400 to RFC822;
- 'table2' and 'gate2' tables map RFC822 into X.400.
- 'table1'と'gate1'はX.400からRFC822までの翻訳を与えます。 - 'table2'と'gate2'テーブルはRFC822を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):
それぞれのマッピングテーブルは配置規則によって構成されます、そして、ただ一つの配置規則はキーワード(翻訳されるためにアドレスから得られたマッピング機能の議論)と翻訳者(マッピング機能パラメタ)によって構成されます:
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 'gate2' table entry is a valid RFC822 domain; thus the usual domain name space can be used without problems to store these entries. On the other hand, the keyword of a 'table1' and 'gate1' 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.
'table2'と'gate2'テーブル項目に関するキーワードは有効なRFC822ドメインです。 したがって、これらのエントリーを保存するのに問題なしで普通のドメイン名スペースを使用できます。 他方では、'table1'と'gate1'エントリーに関するキーワードはスペースという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
可能なソリューションは別の特別なブランチを創設することでした、DNS木の根から始めて、どうにかaddr.arpaの木と同様です。 この考えは、主要な権威を確立するのを必要としたでしょう。
Allocchio Standards Track [Page 5] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[5ページ]。
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.
国際的なレベルで調整するために、それぞれの国家の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. The 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名はそれ自身の構造を引き出します:
. (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 MIXER mapping tables; the use of the Internet DNS gives further motivations for this coordination.
木という全国レベルにおけるX.400の新しい名の作成は国際協調の問題を解決します。 実際に協調問題は全国レベルでただ動かされますが、その結果、それは解決するのが、より簡単になります。 X.400共同体とインターネットの世界の間の全国レベルにおけるコーディネートは既にテーブルを写像する国家の静的なMIXERの作成のための要件です。 インターネットDNSの使用はこのコーディネートに関するさらなる動機を与えます。
Allocchio Standards Track [Page 6] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[6ページ]。
The coordination at national level also fits in the new concept of MCGAM pubblication. The DNS in fact allows a step by step authority distribution, up to a final complete delegation: thus organizations whishing to publish their MCGAM just need to receive delegation also for their branch of the new X.400 name space. 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.
また、全国レベルにおけるコーディネートはMCGAM pubblicationの新しい概念をうまくはめ込みます。 事実上、DNSは段階的な権威分配を最終的な完全な委譲まで許します: したがって、それらのMCGAMを発行するためにwhishingされる組織は、ただ彼らのスペースという新しいX.400名の部門のために委譲をも受ける必要があります。 国家のベースのソリューションのさらなる利点は各国が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 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.
その結果、スペースというDNS名はX.400-RFC822マッピングを実行するためにメールゲートウェイかツールによって必要とされた情報を完全に含んでいます: 最も近いネームサーバへの簡単な質問はそれを提供します。 そのうえ、いいえは、より多くのいずれも手動でどんなマッピングテーブルも保存して、維持して、分配する必要があるあります。 また、スペースという新しいX.400名はX.400共同体に関する詳細を含むことができます、DNSがそれのために完全なセットのリソース記録を許します、そして、その結果、それはさらなる開発を許します。 スペースという新しい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 MIXER mapping rules: PX
4. MIXER配置規則のための新しい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 MCGAMs, 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までマッピングを保存するのに使用されるでしょう。 マッピング情報の上の以上(すなわち、MCGAMs)には、適切なデータ構造と処理を必要とする特定の形式と構文があります。 新しいRRを定義するさらなる利点は何らかの最後の今後の開発のための柔軟性を含む能力です。
Allocchio Standards Track [Page 7] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[7ページ]。
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:
どこ:
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 MCGAM;
<rfc822-ドメイン>、MCGAMのRFC822部分を含むMAP822A<ドメイン名>要素。
MAPX400 A <domain-name> element containing the value of
<x400-in-domain-syntax> derived from the X.400 part of
the MCGAM (see sect. 4.2);
MCGAMの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' or a 'gate1' 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 'gate2' 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'か'gate1'エントリーを保存すると、<名前>はDNS構文でX.400メールドメイン名になるでしょう。(セクトを見てください。 4.2). 私たちが'table2'か'gate2'テーブル項目を保存するとき、<名前>は両方の完全に適切なDNSドメインを含むRFC822メールドメイン名であり、ドメイン(MXだけドメイン)だけを郵送するでしょう。 また、デフォルト値のようなすべての正常なDNSコンベンション(ワイルドカード、略語、およびメッセージ圧縮)が、PX RRのすべての部品に申し込みます。 「<名前>(<ドメイン名>要素としてのMAP822とMAPX400)には、特に、決勝がなければならない」、」 (根) それらは完全に資格があるとき。
Allocchio Standards Track [Page 8] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[8ページ]。
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 MIXER specification for mapping rules. In fact, any MCGAM entry is an implicit wildcard entry, i.e., the rule
PXリソース記録のためのRDATAの定義、DNSが正確な値の区別を許容するという事実、および<名前>パラメタのためのワイルドカードマッチは配置規則のためのMIXER仕様の拡大を表します。 事実上、すなわち、どんなMCGAMエントリーも暗黙のワイルドカードエントリー、規則です。
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 a MCGAM as an exact match only rule. In DNS an entry like
'net2.it'の何らかのサブドメインのための、より詳細な規則が存在していない場合、'net2.it'でどんなRFC822ドメイン結末もカバーしています。 したがって、完全な一致が統治されるだけであるように明らかにMCGAMを指定する可能性が全くありません。 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 MIXER tables. However an entry like
MIXERテーブルのように普通のワイルドカードマッチを指定してください。 しかしながら、エントリーは好きです。
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、-、それ
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 MIXER original syntax.
また、そこのDNS構文によるそれがMAP822とMAPX400分野の周りの'#'デリミタでないことに注意してください: セクトで定義された構文。 4.2 事実上、必要に応じてMIXERのオリジナルの構文で明白なデリミタの使用を不要にして、これらの分野の中に<の空白の>(ASCIIの10進32)にキャラクタを許容しません。
Another extension to the MIXER 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 MIXER 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.
MIXER仕様への別の拡大はPX RDATA部の一部と定義されたPREFERENCE値です。 この数値には、まさに同じ意味がMX RRに使用される同様のものよりあります。 その結果、ドメインのための1つ以上のただ一つのマッピングを指定するのが可能である、(RFC822からX.400までの両方、逆もまた同様に)、好みの命令として、与えます。 しかしながら、MIXERの静的なテーブルでは、あなたはそれぞれの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
X.400推薦では、注意は>がいくつかの特別なケースのために予約されるべきであるADMD=<空白より示されます。 X.400 PRMDがそれが彼らがいるその実際のシングルか複数の接続性の如何にかかわらずそうするべきである国家のADMDsのどれかを通して届くならADMDを使用するX.400 MHS州に、様々な国家の機能的なプロフィール仕様は、この事実の広告を出すために<の空白の>と等しいです。 一方、どんなADMDにもPRMDが接続が全くいないなら、それは状態などに通知するADMD=0を使用するべきです。 しかしながら、現在の現実の状況の大部分では、ADMDサービスプロバイダーが次の状態でメッセージを受け入れない、それら
Allocchio Standards Track [Page 9] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[9ページ]。
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.
彼らにそれら自身のADMD値を持たせて、加入者は彼らであるなら空白のADMDを持っています。 そのような状況に、複数の接続性で適切にドメインのための実際に働くマッピングを示すのにおいて問題があります。 PX RDATA'PREFERENCE'拡張子は、考慮でこれらの問題を取るために紹介されました。
However, as these extensions are not available with MIXER 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.
しかしながら、これらの拡大がMIXERの静的なテーブルで利用可能でないときに、それは、ベースのどんなテーブルでもゲートウェイを織り込むか、アプリケーションであるときに、それらを使用して、強くがっかりしています。 事実上、ただ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 MCGAM 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 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 MCGAM rules (and hence for any X.400 O/R name) which makes it compatible with a <domain-name> element, i.e.,
MCGAM規則の構文定義はそのドキュメントの付録Fで定義されます。 しかしながら、その構文は、それほど指向していた状態で人間でなく、インターネットDNSの他の分野で格別の意味がある多くのキャラクタを含んでいます。 したがって、私たちが特にインターネットでまだ使用されているいくつかの古いDNS実現のためどんな起こりうる問題も避けるためにどんなMCGAM規則の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 MIXER to define MCGAM 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 a MCGAM rule format as:
(RFC1035、セクション2.3.1、8ページを参照します。) <ラベル>のための法的な文字の組はMCGAM規則を定義するのにMIXERで使用されるIA5 Printablestring1に対応していません。 しかしながら、問題を迂回させるために非常に簡単な「逃避機制」を適用できます。 事実上、私たちは、MCGAM規則形式の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
Allocchio Standards Track [Page 10] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[10ページ]。
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 a MCGAM rule in <domain-name> syntax is solved.
<ドメイン名>と<地図規則>に気付くことができるように、同様に見えてください。そうすれば、また、<ラベル>とelemを写像している<>は同じくらい見ます。 私たちが逆もまた同様にelemを写像している<>を<ラベル>に変える正しい方法を定義するなら、<ドメイン名>構文でMCGAM規則を書く問題は解決されています。
The RFC822 domain part of any MCGAM rule is of course already in <domain-name> syntax, and thus remains unchanged.
どんなMCGAM規則のRFC822ドメイン部分ももちろんその結果、<ドメイン名>構文、および残りの中で既に変わりがありません。
In particular, in a 'table1' or 'gate1' 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 'gate2' mapping rule, the 'translator' must be converted into <x400-in-domain-syntax>, while the 'keyword' is already a valid RFC822 domain.
'table1'か'gate1'配置規則では、特に、中の<x400ドメイン構文>(X.400メールDNSメール・ドメイン)に'キーワード'値を変換しなければなりません、'翻訳者'値は既に有効なRFC822ドメインですが。 'table2'か'gate2'配置規則で逆もまた同様です、中の<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 MIXER rules are also mapped as special cases.
unmatching IA5-Printablestringと<ラベル>文字の組定義の問題は簡単なキャラクタ配置規則によって解決されています: そして、IA5キャラクタが<alphanumhyphen>に属さないときはいつも、それは、ハイフンで同封された3ケタ小数ASCIIコードを使用することで写像されます。 また、小さいセットの特別な規則は最も頻繁なケースのために定義されます。 そのうえ、また、MIXER規則で使用されるいくつかの頻繁なキャラクタ組み合わせが特別なケースとして写像されます。
Let's then define the following simple rules:
次に、以下の簡単な規則を定義しましょう:
MCGAM 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
MCGAM規則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>キャラクタ:
MCGAM rule DNS store translation conditions
-----------------------------------------------------------------
- -h- hyphen
\. -d- quoted dot
<blank> -b- blank
<non A/N character> -<3digit-decimal>- elsewhere
MCGAM規則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:
現在、いくつかの例を持ちましょう:
Allocchio Standards Track [Page 11] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[11ページ]。
MCGAM 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
MCGAM規則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 a MCGAM like
したがって、MCGAMからの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
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 a MCGAM 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 MIXER to DNS format (and vice versa) are not user friendly enough to think of a human made conversion.
MCGAMのX.400部分かいかなる他のX.400O/R名の適切なDNS店翻訳も達成するために、いくつかのソフトウェアツールが使用されるでしょう。 事実上、MIXERから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."
「左から右まで五弦を分析しなければなりません、その後の分析で既に翻訳されているのが、ストリングの左のセクションであると再び考えない命令で適切にポインタを動かして。」
Allocchio Standards Track [Page 12] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[12ページ]。
Flow chart 1 - Translation from MIXER to DNS format:
フローチャート1--MIXERから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」を加えます。」 <、-、-、-、-、-、-、-、-、-、-、-、-、--/ | | \---------- 次の属性を取ってください。(もしあれば)
Flow chart 2 - Translation from DNS to MIXER format:
フローチャート2--DNSからMIXERまでの翻訳は以下をフォーマットします。
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」を加えます。」 <、-、-、-、-、-、-、-、-、--/ | | \------------- 次の属性を取ってください。(もしあれば)
Allocchio Standards Track [Page 13] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[13ページ]。
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' or 'gate1' 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.,
'table1'のための値と>を命名するか、またはすなわち、<は'X42D.cc'を加える<に翻訳されたX.400ドメイン価値から派生しているその結果DNSのエントリーがそうするべきである'gate1'ドメイン名>構文を. それへのポストフィックスと命名します。
ADMD$acme.C$fr
ADMD$acme.C$fr
produces in <domain-name> syntax the key:
<ドメイン名>構文で、キーを生産します:
ADMD-acme.C-fr
ADMD-acme.C-fr
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。
Allocchio Standards Track [Page 14] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[14ページ]。
4.3 Creating the appropriate DNS files
4.3 適切なDNSファイルを作成すること。
Using MIXER's assumption of an asymmetric mapping between X.400 and RFC822 addresses, two separate relations are required to store the mapping database: MIXER 'table1' and MIXER 'table2'; thus also in DNS we will maintain the two different sections, even if they will both use the PX resource record. More over MIXER also specify two additional tables: MIXER 'gate1' and 'gate2' tables. These additional tables, however, have the same syntax rules than MIXER 'table1' and 'table2' respectively, and thus the same translation procedure as 'table1' and 'table2' will be applied; some details about the MIXER 'gate1' and 'gate2' tables are discussed in section 4.4.
MIXERのX.400とRFC822アドレスの間の非対称のマッピングの仮定を使用して、2つの別々の関係がマッピングデータベースを格納するのに必要です: ミキサー'table1と'ミキサー'table2'。 したがって、DNSでも、私たちは2の別区を維持するつもりです、ともにPXリソース記録を使用しても。 また、MIXERの上の以上は2個の追加テーブルを指定します: MIXER'gate1'と'gate2'テーブル。 しかしながら、これらの追加テーブルには、同じシンタックス・ルールがそれぞれと、その結果、'table1'と'table2'と同じ翻訳手順がそうするMIXER'table1'と'table2'よりあります。適用されてください。 セクション4.4でMIXER'gate1'と'gate2'テーブルに関するいくつかの詳細について議論します。
Let's now check how to create, from an MCGAM entry, the appropriate DNS entry in a DNS data file. We can again define an MCGAM entry as defined in appendix F of that document as:
現在、MCGAMエントリーからDNSデータファイルにおける適切なDNSエントリーを作成する方法をチェックしましょう。 私たちは再びそのドキュメントの付録Fで定義されるMCGAMエントリーを以下と定義できます。
<x400-domain>#<rfc822-domain># (case A: 'table1' and 'gate1'
entry)
<x400-ドメイン>#<rfc822-ドメイン>#(ケースA:'table1'と'gate1'エントリー)
and
そして
<rfc822-domain>#<x400-domain># (case B: 'table2' and 'gate2'
entry)
<rfc822-ドメイン>#<x400-ドメイン>#(ケースB: 'table2'と'gate2'エントリー)
The two cases must be considered separately. Let's consider case A.
別々に2つのケースを考えなければなりません。 ケースAを考えましょう。
- 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' and 'gate1' entry.
PX RDATAの中では、<rfc822-ドメイン>は'table1'と'gate1'エントリーにも中の<x400ドメイン構文>に先行します。
an example: from the 'table1' rule
例: 'table1'規則から
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」で終わってください。」
Allocchio Standards Track [Page 15] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[15ページ]。
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 'table2' rule
例: 'table2'規則から
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.
もう一度完全に適切な<ドメイン名>要素に注意してください。
A file containing the MIXER mapping rules and MIXER 'gate1' and 'gate2' table written in DNS format will look like the following fictious example:
DNS形式で書かれたMIXER配置規則、MIXER'gate1'、および'gate2'テーブルを入れてあるファイルは以下のfictiousの例に似るでしょう:
!
! MIXER 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.
!
! MIXER 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.
!
! MIXER Gate 1 Table
!
*.ADMD-XKW-h-Mail.X42D.it. IN PX 50 \
XKW-gateway.it. ADMD-XKW-h-Mail.C-it.G.
*.PRMD-Super-b-Inc.ADMDb.X42D.it. IN PX 50 \
GlobalGw.it. PRMD-Super-b-Inc.ADMDb.C-it.G.
!
! MIXER Gate 2 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.
MIXERのテーブルの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、-、それ ! ! MIXERテーブル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、-、それ ! ! ミキサーゲート1は*.ADMD-XKW-h-Mail.X42D.をテーブルの上に置きます。それ。 PXの50円のXKW-gateway.itで。 ADMD-XKW-h-Mail.C-it.G.*.PRMD超bの株式会社ADMDb.X42D.、それ。 PXの50円のGlobalGw.itで。 PRMD超bの株式会社のADMDb.C-it.G.!MIXER Gate2Table!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。
Allocchio Standards Track [Page 16] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[16ページ]。
(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 'gate1' and 'gate2' Tables section whose aim is described in section 4.4. The corresponding MIXER tables are:
目的がセクション4.4で説明される'gate1'と'gate2'テーブルの右側の特別な接尾語".G."セクションに注意してください。 対応するMIXERテーブルは以下の通りです。
#
# MIXER 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#
#
# MIXER 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#
#
# MIXER Gate 1 Table
#
ADMD$XKW-Mail.C$it#XKW-gateway.it#
PRMD$Super Inc.ADMD$ .C$it#GlobalGw.it#
#
# MIXER Gate 2 Table
#
my.it#OU$int-gw.O$@.PRMD$ninp.ADMD$acme.C$it#
co.it#O$mhs-relay.PRMD$x4net.ADMD$ .C$t#
# # MIXERテーブル1: X.400--、>RFC822#ADMD$acme.C$、それ、#、それ、#PRMD$accred.ADMD$tx400.C$、それ、#accred.it#O$u-newcity.PRMD$x4net.ADMD$.C$、それ、#cs.ncty.it###MIXERテーブル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$、それ、###MIXER Gate1Table#ADMD$XKW-Mail.Cドル、それ、#XKW-gateway.it#PRMD$Super株式会社ADMD$.C$、それ、#GlobalGw.it###MIXER Gate2Table#my.it# OU$int-gw.O$@.PRMD$ninp.ADMD$acme.C$it #co.it#O$mhs-relay.PRMD$x4net.ADMD$.C$t#
4.4 Storing the MIXER 'gate1' and 'gate2' tables
4.4 MIXER'gate1'と'gate2'テーブルを収納すること。
Section 4.3.4 of MIXER 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 MIXER 'gate2' table is thus introduced.
また、.4セクション4.3MIXERが完全なマッピングが不可能であるといけないのでアドレスがRFC822とX.400の間でどう変換されるべきであるかを指定します。 DDAsの非mappableドメインの使用を許すために、MIXER'gate2'テーブルはこのようにして紹介されます。
In a totally similar way, when an X.400 address cannot be completely converted in RFC822, section 4.3.5 of MIXER specifies how to encode (LHS encoding) the address itself, pointing then to the appropriate MIXER conformant gateway, indicated in the MIXER 'gate1' table.
RFC822で完全にX.400アドレスを変換できるというわけではないとき、完全に同様の方法で、.5セクション4.3MIXERがアドレス自体をコード化する(LHSコード化)方法を指定します、その時MIXER'gate1'テーブルで示された適切なMIXER conformantゲートウェイを示して。
DNS must store and distribute also these 'gate1' and 'gate2' data.
また、DNSはこれらの'gate1'と'gate2'データを格納して、分配しなければなりません。
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
DNSの主要な特徴の1つは権威を分配する能力です: ある一定のサイトは1つの決定している下位木のために「第一」のネームサーバを走らせます、そして、その結果、また、それはその下位木の情報をアップデートできた唯一の場所です。 この事実が中に許容する、私たち
Allocchio Standards Track [Page 17] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[17ページ]。
case, a further additional feature to the table based approach. In fact we can avoid one possible ambiguity about the use of the 'gate1' and 'gate2' tables (and thus of LHS and DDAs encoding).
ケース、テーブルへのさらなる付加的な機能はアプローチを基礎づけました。 事実上、私たちが'gate1'と'gate2'テーブルの使用に関して1つの可能なあいまいさを避けることができる、(その結果、LHSと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 'gate2' table entry. Thus for an RFC822 domain we cannot have any more two possible entries, one from 'table2 and another one from 'gate2' 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'エントリーになる、さもなければ、それは'gate2'テーブル項目になるでしょう。 したがって、RFC822ドメインに、私たちは''gate2'テーブルからのtable2と別の1つ、および結果が明確に述べたゲートウェイのための動作'からのそれ以上の2つの可能なエントリー、1を持つことができません。
Similarly, the authority mantaining a DNS entry in the new X.400 name space is the only one allowed to decide if its X.400 domain should be mapped using SA syntax or Left Hand Side (LHS) encoding. If the authority decides that its X.400 domain should be mapped using SA, then the PX RDATA will be a 'table1' entry, otherwise it will be a 'gate1' table entry. Thus also for an X.400 domain we cannot have any more two possible entries, one from 'table1' and another one from 'gate1' table, and the action for a gateway results clearly stated.
同様に、新しいX.400名前スペースでDNSエントリーをmantainingする権威はX.400ドメインがSA構文かLeft Hand Side(LHS)コード化を使用することで写像されるべきであるかどうか決めることができた唯一無二です。 権威が、X.400ドメインがSAを使用することで写像されるべきであると決めるならPX RDATAが'table1'エントリーになる、さもなければ、それは'gate1'テーブル項目になるでしょう。 したがって、X.400ドメインにも、私たちは可能なエントリー、'table1'からのもの、および'gate1'からの別の1つが見送るそれ以上の2、および結果が明確に述べたゲートウェイのための動作を持つことができません。
The MIXER 'gate1' table syntax is actually identical to MIXER
'table1', and 'gate2' table syntax is identical to MIXER 'table2'.
Thus the same syntax translation rules from MIXER to DNS format can
be applied in both cases. However a gateway or any other application
must know if the answer it got from DNS contains some 'table1',
'table2' or some 'gate1', 'gate2' table information. This is easily
obtained flagging with an additional ".G." post-fix the PX RDATA
value when it contains a 'gate1' or 'gate2' 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 MIXER 'gate1' or 'gate2' table
data.
MIXER'gate1'テーブルシンタックスは実際にMIXER'table1'と同じです、そして、'gate2'テーブルシンタックスはMIXER'table2'と同じです。 したがって、どちらの場合も、同じMIXERからDNS形式までの構文翻訳規則を適用できます。 しかしながら、ゲートウェイかアプリケーションが、いかなる他のもそれがDNSから得た答えがいくつかの'table1'、'table2'またはいくつかの'gate1'('gate2'テーブル情報)を含むかどうかを知らなければなりません。 'gate1'か'gate2'テーブル項目を含んでいると追加".G."ポストフィックスでPX RDATA値に旗を揚げさせながら、容易にこれを得ます。 セクション4.3の例は明確に結果を示しています。 どんなX.400O/Rドメインも国名略号(私たちのDNS構文による「C-xx」)で終わらなければならない間、追加".G."はどんな闘争もあいまいさも全く引き起こしません。 MIXER'gate1'か'gate2'テーブルデータを使用する前に、明らかにこのポストフィックスを取り除かなければなりません。
5. Finding MIXER mapping information from DNS
5. DNSからMIXERがマッピング情報であることがわかります。
The MIXER 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.
MIXERマッピング情報は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 be performed (MIXER: section 4.3.4, State I; section 4.3.5, mapping
マッピング情報がDNSに格納されるとき、マッピングテーブルを通した繰り返しの検索が実行されるだろうというときはいつも、DNSへの質問が発行される、(MIXER: 州I; セクション4.3.4、セクション4.3.5は写像されます。
Allocchio Standards Track [Page 18] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[18ページ]。
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 MIXER, a search of the mapping table will result in either success (mapping found) or failure (query failed, mapping not found).
B)。 DNS検索メカニズムのため、それ自体でDNSはただ一つの質問と共に格納された配置規則における可能な限り長いマッチを返します、その結果、繰り返しでない、そして/または、複数の質問が必要です。 MIXERで指定されるように、マッピングテーブルの検索は成功(見つけられたマッピング)か失敗のどちらかをもたらすでしょう(質問が失敗しました、とマッピングによって、わかりませんでした)。
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 MIXER. 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番目の可能な結果はタイムアウトです。 結果がタイムアウトであるなら、ゲートウェイ操作は、後で遅れて、次に、再試行されます。 MIXERで指定されたアルゴリズムによると、成否の結果は処理されます。 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 MIXER mail-gateway located in the Internet, when translating addresses from RFC822 to X.400, can get information about the MCGAM 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までアドレスを翻訳するときインターネットに位置するMIXERメール・ゲートウェイで、MCGAM規則の情報は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 MIXER Table 2 mapping rule will be obtained.
その結果、".G."が全く得られたPX RDATA価値の終わりになくて、ミキサーテーブル2配置規則を得て、パラグラフ4.2で指定された構文翻訳を適用するでしょう。
Let's now take another example where a 'gate2' 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,
現在、'gate2'テーブル規則が返される別の例を取りましょう。 私たちが先端がある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 'gate2' 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 the gateway to use DDA encoding for the inquired RFC822 domain.
DNSはすなわち、'mw''O-cce.PRMD-nrc.ADMD-acme.C-it.G.'、'gate2'にDNS店形式におけるテーブル項目を返すでしょう。 最終的な".G."を落として、パラグラフ4.2で指定された構文翻訳を適用して、オリジナルの規則は利用可能になるでしょう。 また、".G."旗は、問い合わせられたRFC822ドメインのためのDDAコード化を使用するようにゲートウェイにより言います。
Allocchio Standards Track [Page 19] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[19ページ]。
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 MIXER 'table1' rule in encoded format.
より特定の記録がDNSにないと仮定すると、ワイルドカードメカニズムはコード化された形式でMIXER'table1'規則を返すでしょう。
Finally, an example where a 'gate1' rule is involved. If we are looking for an X.400 domain ending with ADMD=PWT400; C=US; , and the DNS contains a PX record like this,
最終的に'gate1'規則がかかわる例。 私たちがADMD=PWT400があるX.400ドメイン結末を探しているなら。 Cは米国と等しいです。 , そして、DNSはこのようなPX記録を含んでいます。
*.ADMD-PWT400.X42D.us. IN PX 50 intGw.com. ADMD-PWT400.C-us.G.
*.ADMD-PWT400.X42D.、私たち。 PX50intGw.comで。 ADMD-PWT400.C-us.G。
DNS will return 'intGw.com.' and 'ADMD-PWT400.C-us.G.', i.e., a 'gate1' 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 the gateway to use LHS encoding for the inquired X.400 domain.
DNSはすなわち、'intGw.com''ADMD-PWT400.C-us.G.'、'gate1'にDNS店形式におけるテーブル項目を返すでしょう。 最終的な".G."を落として、パラグラフ4.2で指定された構文翻訳を適用して、オリジナルの規則は利用可能になるでしょう。 また、".G."旗は、照会のためにX.400ドメインをコード化する左手を使用するようにゲートウェイにより言います。
6. Administration of mapping information
6. マッピング情報の政権
The DNS, using the PX RR, is able to distribute the MCGAM rules to all MIXER gateways located on the Internet. However, not all MIXER 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はインターネットに位置するすべてのMIXERゲートウェイにMCGAM規則を分配できます。 しかしながら、すべてのMIXERゲートウェイがどんなインターネットDNSを使用できるというわけではないでしょう。 特定の管理ドメインの数門が以下のモデルのひとりに一致すると予想されます:
(a) Table-based, (b) DNS-based, (c) X.500-based
(a) テーブルベースである、(b)、DNSベースである、(c)、X.500ベース
Table-based management domains will continue to publish their MCGAM rules and retrieve the mapping tables via the International Mapping Table coordinator, manually or via some automated procedures. Their MCGAM information can be made available also in DNS by the appropriate DNS authorities, using the same mechanism already in place for MX records: if a branch has not yet in place its own DNS
テーブルベースの管理ドメインは、国際Mapping Tableコーディネータを通してそれらのMCGAM規則を発表して、マッピングテーブルを検索し手動かいくつかの自動化手順で続けるでしょう。 それらのMCGAM情報をDNSでも適切なDNS当局で利用可能にすることができます、MX記録に適所で既に同じメカニズムを使用して: ブランチが今まで適所でそうしていない、それ自身のDNS
Allocchio Standards Track [Page 20] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[20ページ]。
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 specification. An informational document describing the implementation phase and the detailed coordination procedures is expected.
サーバ、DNS木の何らかのより高い権威がそれのためのサービスを提供するでしょう。 また、'hosts.txt'テーブルからDNSまで移動するのに使用されるものと同様の変遷手順をこの仕様の展開フェーズに適用できます。 実施フェーズと詳細な協力手順を説明する情報のドキュメントは予想されます。
Another distributed directory service which can distribute the MCGAM information is X.500. Coordination with table-based domains can be obtained in an identical way as for the DNS case.
MCGAM情報を分配できる別の分配された電話番号案内はX.500です。 DNSケースのように同じ方法でテーブルベースのドメインがあるコーディネートを得ることができます。
Coordination of MCGAM information between DNS and X.500 is more complex, as it requies some kind of uploading information between the two systems. 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.
それとしての、より多くの複合体が2台のシステムの間のrequiesある種のアップロード情報ですか?理想的な解決が透明に逆もまた同様にDNSをX.500で利用可能なマッピング情報にするダイナミックアライメントメカニズムであるというDNSとX.500の間のMCGAM情報のコーディネート。 この特定の分野でのいくらかの仕事は既に情報がDNSに格納されるところかX.500でグローバルな透明な電話番号案内をもたらすことができますが、完全に2台のシステムのいずれでも目に見えるすることです[コスタを見ます]。
However we must remind that MIXER concept of MCGAM rules publication is different from the old RFC1327 concept of globally distributed, coordinated and unique mapping rules. In fact MIXER does not requires any more for any conformant gateway or tool to know the complete set of MCGAM: it only requires to use some set (eventually empty) of valid MCGAM rules, published either by Tables, DNS or X.500 mechanisms or any combination of these methods. More over MIXER specifies that also incomplete sets of MCGAM can be used, and supplementary local unpublished (but valid) MCGAM can also be used. As a consequence, the problem of coordination between the three systems proposed by MIXER for MCGAM publication is non essential, and important only for efficient operational matters. It does not in fact affect the correct behaviour of MIXER conformant gateways and tools.
私たちがどのようにそのMIXERに思い出させなければならなくても、MCGAMの概念は、公表がグローバルに分配されて、連携していてユニークな配置規則の古いRFC1327概念と異なっていると裁決します。 事実上、MIXERが必要である、どんなconformantゲートウェイかMCGAMの完全なセットを知るツールのためにももう以下を必要としません。 それはこれらの方法のTables、DNS、X.500メカニズムまたはどんな組み合わせでも発表された何らかのセット(結局空の)の有効なMCGAM規則を使用に必要とするだけです。 MIXERの上の以上はまた、MCGAMの不完全なセットを使用できて、また、補っている地方の未発表の、そして、(有効)のMCGAMを使用できると指定します。 結果として、MCGAM公表のためにMIXERによって提案された3台のシステムの間のコーディネートの問題は、非不可欠であって、効率的な操作上の件だけに、重要です。 事実上、それはMIXER conformantゲートウェイと道具の正しいふるまいに影響しません。
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 MCGAM 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 were been performed under the provisional top level domain "X400.IT" when RFC1664 was developed, and their results confirmed the advantages of the method. Operational exeprience for over 2 years with RFC1664 specification
新しいPXリソース記録の導入とDNS構造とのスペースというX.400O/R名の定義は良い倉庫をMCGAM情報に提供します。 マッピング情報がDNS木構造に格納されるので、DNSを使用することで容易にそれを得ることができるのは名前サービスを広げました。 ある他のX.400 MHS情報をX.400O/Rのための適切なDNSスペースの定義が命名する同時に、どこを倉庫に供給するか、そして、格納して、分配してください。 DNSの使用は情報を格納して、管理して、アップデートする際に多くの知られている利点を持っています。 うまくいっている数のテストがそうでした。RFC1664が開発されて、それらの結果が方法の利点を確認した暫定的なトップ・レベル・ドメイン"X400.IT"の下で実行されます。 RFC1664仕様がある2年間以上の操作上のexeprience
Allocchio Standards Track [Page 21] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[21ページ]。
confirmed the feasibility of the method, and helped identifying some operational procedures to deploy the insertion of MCGAM into DNS.
MCGAMの挿入をDNSに配備するために方法に関する実現の可能性を確認して、いくつかの操作手順を特定するのを助けました。
Software to query the DNS and then to convert between the textual representation of DNS resource records and the address format defined in MIXER was developed with RFC1664. This software also allows a smooth implementation and deployment period, eventually taking care of the transition phase. This software can be easily used (with little or null modification) also for this updated specification, supporting the new 'gate1' MIXER table. DNS software implementations supporting RFC1664 also supports with no modification this memo new specification.
DNSについて質問して、そして、DNSリソース記録の原文の表現とMIXERで定義されたアドレス形式の間で変換するソフトウェアはRFC1664と共に開発されました。 また、結局過渡期の世話をして、このソフトウェアは滑らかな実現と展開の期間を許容します。 また、このアップデートされた仕様に容易にこのソフトウェアを使用できます(小さいかヌルの変更で)、新しい'gate1'MIXERテーブルを支えて。 また、RFC1664を支持するDNSソフトウェア実行が変更なしでこのメモの新しい仕様を支持します。
Allocchio Standards Track [Page 22] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[22ページ]。
A further informational document describing operational and implementation of the service is expected.
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, TERENA wg-msg and IETF namedroppers groups. A special mention to Christian Huitema for his fundamental contribution to this work.
私たちは感謝にこのドキュメントの議論と改正に貢献した人を願っています: 彼らの考えと提案の多くがこの仕事の不可欠の部分を構成します。 ジョン・ポステル、ポールMockapetris、ロブオースチン、全体のIETF x400ops、TERENA wg-msg、およびIETF namedroppersグループを特にありがとうございます。 この仕事への彼の基本的貢献のためのクリスチャンのHuitemaへの特記。
This document is a revision of RFC1664, edited by one of its authors on behalf of the IETF MIXER working group. The current editor wishes to thank here also the authors of RFC1664:
このドキュメントはIETF MIXERワーキンググループを代表して作者のひとりによって編集されたRFC1664の改正です。 現在のエディタはここでの感謝にもRFC1664の作者を願っています:
Antonio Blasco Bonito RFC822: bonito@cnuce.cnr.it
CNUCE - CNR X.400: C=it;A=garr;P=cnr;
Reparto infr. reti O=cnuce;S=bonito;
Viale S. Maria 36
I 56126 Pisa
Italy
アントニオBlascoかつおのRFC822: bonito@cnuce.cnr.it CNUCE--、CNR X.400: Cはそれ; A=garr; P=cnrと等しいです。 Reparto infr. reti O=cnuce; Sはかつおと等しいです。 ビアール・S.マリア36I56126Pisaイタリア
Bruce Cole RFC822: bcole@cisco.com
Cisco Systems Inc. X.400: C=us;A= ;P=Internet;
P.O. Box 3075 DD.rfc-822=bcole(a)cisco.com;
1525 O'Brien Drive
Menlo Park, CA 94026
U.S.A.
ブルースコールRFC822: bcole@cisco.com シスコシステムズInc.X.400: C=私たち; =; Pはインターネットと等しいです。 私書箱3075DD.rfc-822=bcole(a)cisco.com。 1525オブライエン・Driveカリフォルニア94026メンローパーク(米国)
Silvia Giordano RFC822: giordano@cscs.ch
Centro Svizzero di X.400: C=ch;A=arcom;P=switch;O=cscs;
Calcolo Scientifico S=giordano;
Via Cantonale
CH 6928 Manno
Switzerland
シルビアジョルダーノRFC822: giordano@cscs.ch セントロSvizzeroディX.400: C=ch; A=arcom; Pはスイッチと等しいです; O=cscs Calcolo Scientifico S=giordano。 Cantonale CH6928Mannoスイス経由で
Robert Hagens RFC822: hagens@ans.net
Advanced Network and Services X.400: C=us;A= ;P=Internet;
1875 Campus Commons Drive DD.rfc-822=hagens(a)ans.net;
Reston, VA 22091
U.S.A.
ロバートHagens RFC822: hagens@ans.net はネットワークとサービスX.400を唱えました: C=私たち; =; Pはインターネットと等しいです。 1875年のキャンパス下院はDD.rfc-822=hagens(a)ans.netを運転します。 レストン、ヴァージニア22091米国
Allocchio Standards Track [Page 23] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[23ページ]。
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月。
[RFC 2156] Kille, S. E., " MIXER (Mime Internet X.400 Enhanced
Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156,
January 1998.
Kille、[RFC2156]S.E.、「ミキサー(パントマイムインターネットX.400はリレーを機能アップしました):」 「X.400とRFC822/の間でMIMEを写像します」、RFC2156、1998年1月。
[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がそうするかもしれません。
10. Security Considerations
10. セキュリティ問題
This document specifies a means by which DNS "PX" records can direct the translation between X.400 and Internet mail addresses.
このドキュメントはDNS"PX"記録がX.400とインターネット郵便の宛先の間の翻訳を指示できる手段を指定します。
This can indirectly affect the routing of mail across an gateway between X.400 and Internet Mail. A succesful attack on this service could cause incorrect translation of an originator address (thus "forging" the originator address), or incorrect translation of a recipient address (thus directing the mail to an unauthorized recipient, or making it appear to an authorized recipient, that the message was intended for recipients other than those chosen by the originator) or could force the mail path via some particular gateway or message transfer agent where mail security can be affected by compromised software.
これは間接的にX.400とインターネットメールの間のゲートウェイの向こう側のメールのルーティングに影響できます。 このサービスに対するsuccesful攻撃は創始者アドレスに関する誤訳を引き起こす場合がありました(その結果、創始者アドレスを「鍛造します」); または、受取人アドレスに関する誤訳、(その結果、権限のない受取人にメールを向ける、または、それを作るのは認可された受取人にとって現れて、メッセージは創始者によって選ばれたもの以外の受取人のために意図しました)、メールセキュリティが妥協しているソフトウェアで影響を受けることができるところに何らかの特定のゲートウェイかメッセージ転送エージェントを通したメール経路を強制できました。
Allocchio Standards Track [Page 24] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[24ページ]。
There are several means by which an attacker might be able to deliver incorrect PX records to a client. These include: (a) compromise of a DNS server, (b) generating a counterfeit response to a client's DNS query, (c) returning incorrect "additional information" in response to an unrelated query.
攻撃者が不正確なPX記録をクライアントに送ることができるかもしれないいくつかの手段があります。 これらは: (a) DNSサーバ、クライアントのDNS質問(関係ない質問に対応して不正確な「追加情報」を返す(c))へのにせの応答を発生させる(b)の妥協。
Clients using PX records SHOULD ensure that routing and address translations are based only on authoritative answers. Once DNS Security mechanisms [RFC 2065] become more widely deployed, clients SHOULD employ those mechanisms to verify the authenticity and integrity of PX records.
PX記録SHOULDを使用しているクライアントは、ルーティングとアドレス変換が正式の答えだけに基づいているのを保証します。 DNS Securityメカニズム[RFC2065]がいったん広くより配備されるようになると、クライアントSHOULDは、PX記録の信憑性と保全について確かめるのにそれらのメカニズムを使います。
11. Author's Address
11. 作者のアドレス
Claudio Allocchio Sincrotrone Trieste SS 14 Km 163.5 Basovizza I 34012 Trieste Italy
クラウディオAllocchio SincrotroneトリエステSS14km163.5Basovizza I34012トリエステイタリア
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 3758565
RFC822: Claudio.Allocchio@elettra.trieste.it X.400: C=それ; A=garr; Pはトリエステと等しいです; Oはエレットラと等しいです。 S=Allocchio; Gはクラウディオと等しいです。 以下に電話をしてください。 +39 40 3758523、Fax: +39 40 3758565
Allocchio Standards Track [Page 25] RFC 2163 MIXER MCGAM January 1998
Allocchio規格はミキサーMCGAM1998年1月にRFC2163を追跡します[25ページ]。
12. Full Copyright Statement
12. 完全な著作権宣言文
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 Standards Track [Page 26]
Allocchio標準化過程[26ページ]
一覧
スポンサーリンク
