Network Working Group Internet Architecture Board (IAB)
Request for Comments: 2825 L. Daigle, Editor
Category: Informational May 2000
A Tangled Web: Issues of I18N, Domain Names, and the
Other Internet protocols
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
The goals of the work to "internationalize" Internet protocols include providing all users of the Internet with the capability of using their own language and its standard character set to express themselves, write names, and to navigate the network. This impacts the domain names visible in e-mail addresses and so many of today's URLs used to locate information on the World Wide Web, etc. However, domain names are used by Internet protocols that are used across national boundaries. These services must interoperate worldwide, or we risk isolating components of the network from each other along locale boundaries. This type of isolation could impede not only communications among people, but opportunities of the areas involved to participate effectively in e-commerce, distance learning, and other activities at an international scale, thereby retarding economic development.
インターネットプロトコルを「国際化」する作業の目標は、自分自身を表現名前を書き、ネットワークをナビゲートするために、独自の言語とその標準文字セットを使用する機能で、インターネットのすべてのユーザーを提供することを含みます。ドメイン名、電子メールアドレスに表示し、国境を越えて使用されているが、ドメイン名はインターネット・プロトコルによって使用されているWorld Wide Web上の情報を見つけるために使用今日のURLなどのように多くの影響を及ぼします。これらのサービスは、世界的に相互運用しなければならない、あるいは我々は、ロケールの境界に沿って互いにネットワークのコンポーネントを分離する危険性があります。分離のこのタイプは、人々の間だけでなく、通信を妨げる可能性がありますが、エリアの機会が、それによって経済発展を遅らせること、国際的な規模での電子商取引、遠隔教育、および他の活動に効果的に参加して関与しました。
There are several proposals for internationalizing domain names, however it it is still to be determined whether any of them will ensure this interoperability and global reach while addressing visible-name representation. Some of them obviously do not. This document does not attempt to review any specific proposals, as that is the work of the Internationalized Domain Name (IDN) Working Group of the IETF, which is tasked with evaluating them in consideration of the continued global network interoperation that is the deserved expectation of all Internet users.
ドメイン名の国際化のためのいくつかの提案は、しかし、それが可視名表現に対処しながら、それらのいずれかが、この相互運用性とグローバルな展開を確実にするかどうかを決定することがまだある、があります。それらのいくつかは明らかにしません。それはの当然期待され続け、グローバルネットワークの相互運用を考慮して、それらを評価する使命を帯びているIETFの国際化ドメイン名（IDN）ワーキンググループの仕事であるとしてこの文書は、任意の具体的な提案を検討しようとしません。すべてのインターネットユーザー。
This document is a statement by the Internet Architecture Board. It is not a protocol specification, but an attempt to clarify the range of architectural issues that the internationalization of domain names faces.
このドキュメントはインターネットアーキテクチャ委員会の声明です。これは、プロトコル仕様ではなく、ドメイン名の国際化が直面している建築の問題の範囲を明確にしようとする試み。
The Internationalized Domain Names (IDN) Working Group is one component of the IETF's continuing comprehensive effort to internationalize language representation facilities in the protocols that support the global functioning of the Internet.
国際化ドメイン名（IDN）ワーキンググループは、インターネットの世界的な機能をサポートするプロトコルで言語表現施設を国際化するIETFの継続的な包括的な取り組みの1つの構成要素です。
In keeping with the principles of rough consensus, running code, architectural integrity, and in the interest of ensuring the global stability of the Internet, the IAB emphasizes that all solutions proposed to the (IDN) Working Group will have to be evaluated not only on their individual technical features, but also in terms of impact on existing standards and operations of the Internet and the total effect for end-users: solutions must not cause users to become more isolated from their global neighbors even if they appear to solve a local problem. In some cases, existing protocols have limitations on allowable characters, and in other cases implementations of protocols used in the core of the Internet (beyond individual organizations) have in practice not implemented all the requisite options of the standards.
ラフコンセンサスの原則を維持するには、コード、建築の整合性、およびインターネットのグローバルな安定性を確保するの利益のために、IABは、すべてのソリューションは、（IDN）ワーキンググループがないだけに、評価されなければならないに提案することを強調を実行します個々の技術的な特徴が、また、既存の標準とインターネットとエンドユーザーのための総効果の業務への影響の観点から：彼らはローカルの問題を解決するように見える場合でも、ソリューションは、ユーザーが自分のグローバルな隣人からより孤立させてはなりません。いくつかのケースでは、既存のプロトコルは、可能な文字に制限があり、それ以外の場合には（個々の組織を超えて）インターネットのコアに使用されるプロトコルの実装は、実際には標準のすべての必要なオプションを実装していません。
In many technical respects, the IDN work is not different from any other effort to enable multiple character set representations in textual elements that were traditionally restricted to English language characters.
多くの技術的な点で、IDNの作品は、伝統的に英語の文字に制限されたテキスト要素に複数の文字セットの表現を可能にするために、他の努力と変わりません。
One aspect of the challenge is to decide how to represent the names users want in the DNS in a way that is clear, technically feasible, and ensures that a name always means the same thing. Several proposals have been suggested to address these issues.
挑戦の一の態様は、ユーザーが明確な、技術的に実現可能な方法でDNSにしたい名前を表現する方法を決定することであり、名前は常に同じことを意味することを保証します。いくつかの提案は、これらの問題に対処するために提案されています。
These issues are being outlined in more detail in the IDN WG's evolving draft requirements document; further discussion is deferred to the WG and its documents.
これらの問題は、IDN WGの進化ドラフト要件文書でより詳細に概説されています。さらなる議論は、WG及びその文書に延期されます。
Nevertheless, issues faced by the IDN working group are complex and intricately intertwined with other operational components of the Internet. A key challenge in evaluating any proposed solution is the analysis of the impact on existing critical operational standards which use fully-qualified domain names [RFC1034], or simply host names [RFC1123]. Standards-changes can be effected, but the best path forward is one that takes into account current realities and (re)deployment latencies. In the Internet's global context, it is not enough to update a few isolated systems, or even most of the systems in a country or region. Deployment must be nearly universal in order to avoid the creation of "islands" of interoperation that provide users with less access to and connection from the rest of the world.
それにも関わらず、IDNワーキンググループが直面する問題は複雑で、インターネットの他の動作コンポーネントと複雑に絡み合っています。どんな提案されたソリューションを評価する上で重要な課題は、完全修飾ドメイン名[RFC1034]を使用する既存の重要な運用基準への影響の分析である、または単に名前[RFC1123]をホストします。標準規格の変更を行うことができますが、前方の最適なパスを考慮に入れ、現在の現実と（再）導入の待ち時間を要するものです。インターネットのグローバルな文脈では、いくつかの孤立システムを更新するのに十分ではない、または国や地域内のシステムのも、最も。展開はあまりへのアクセスと世界の残りの部分からの接続をユーザーに提供する相互運用の「島」の作成を避けるために、ほぼ普遍的でなければなりません。
These are not esoteric or ephemeral concerns. Some specific issues have already been identified as part of the IDN WG's efforts. These include (but are not limited to) the following examples.
これらは、難解なまたは一時的な懸念事項ではありません。いくつかの特定の問題は、すでにIDN WGの取り組みの一環として同定されています。これらは、（これに限定されないが）以下の例。
As indicated in the IDN WG's draft requirements document, the issue goes beyond standardization of DNS usage. Electronic mail has long been one of the most-used and most important applications of the Internet. Internet e-mail is also used as the bridge that permits the users of a variety of local and proprietary mail systems to communicate. The standard protocols that define its use (e.g., SMTP [RFC821, RFC822] and MIME [RFC2045]) do not permit the full range of characters allowed in the DNS specification. Certain characters are not allowed in e-mail address domain portions of these specifications. Some mailers, built to adhere to these specifications, are known to fail when on mail having non-ASCII domain names in its address -- by discarding, misrouting or damaging the mail. Thus, it's not possible to simply switch to internationalized domain names and expect global e-mail to continue to work until most of the servers in the world are upgraded.
IDN WGの草稿要件ドキュメントに示されているように、問題はDNSの使用量の標準化を超えています。電子メールは、長い間、インターネットの最も使用され、最も重要なアプリケーションの一つとなっています。インターネット電子メールは、ローカルおよび独自メールシステムの種々のユーザが通信することを可能にするブリッジとして使用されます。その使用を定義する標準的なプロトコル（例えば、SMTP [RFC821、RFC822]とMIME [RFC2045]）DNS仕様で許容される文字の完全な範囲を許可しません。特定の文字は、これらの仕様の電子メールアドレスのドメイン部分では許可されません。 、廃棄misroutingやメールにダメージを与えることで - これらの仕様に準拠して構築されたいくつかのメーラは、メールでそのアドレスに非ASCIIドメイン名を持つときに失敗することが知られています。したがって、それは単に世界でのサーバーのほとんどがアップグレードされるまで作業を継続するために国際化ドメイン名に切り替え、グローバル電子メールを期待することはできません。
At a lower level, the Routing Policy Specification Language (RPLS) [RFC2622] makes use of "named objects" -- and inherits object naming restrictions from older standards ([RFC822] for the same e-mail address restrictions, [RFC1034] for hostnames). This means that until routing registries and their protocols are updated, it is not possible to enter or retrieve network descriptions utilizing internationalized domain names.
以下のために[RFC1034]、同じ電子メールアドレス制限のために[RFC822]（古い標準からの命名制限オブジェクトと継承 - 下位レベルでは、ルーティングポリシー仕様言語（RPLS）[RFC2622]は、「名前付きオブジェクト」を使用していますホスト名）。これは、レジストリをルーティングし、そのプロトコルが更新されるまで、国際化ドメイン名を利用したネットワークの説明を入力するか、または取得することはできないことを意味します。
Also, the Simple Network Management Protocol (SNMP) uses the textual representation defined in [RFC2579]. While that specification does allow for UTF-8-based domain names, an informal survey of deployed implementations of software libraries being used to build SNMP-compliant software uncovered the fact that few (if any) implement it.
また、簡易ネットワーク管理プロトコル（SNMP）は、[RFC2579]で定義されたテキスト表現を使用しています。その仕様は、UTF-8ベースのドメイン名を許可しないが、SNMP準拠のソフトウェアを構築するために使用されているソフトウェアライブラリの展開実装の非公式の調査では、（もしあれば）、数がそれを実装しているという事実を明らかにしました。
This may cause inability to enter or display correct data in network management tools, if such names are internationalized domain names.
これは、入力するか、またはそのような名前は、国際化ドメイン名であれば、ネットワーク管理ツールで正しいデータを表示できないことが発生することがあります。
Critical components of Internet public key technologies (PKIX, [RFC2459], IKE [RFC2409]) rely heavily on identification of servers (hostnames, or fully qualified domain names) and users (e-mail addresses). Failure to respect the character restrictions in these protocols will impact security tools built to use them -- Transport Layer Security protocol (TLS, [RFC2246]), and IPsec [RFC2401] to name two.
インターネット公開鍵技術の重要なコンポーネント（PKIX、[RFC2459]は、IKEは、[RFC2409]）のサーバー（ホスト名、または完全修飾ドメイン名）とユーザー（電子メールアドレス）の識別に大きく依存しています。 2に名前を付けるためにトランスポート層セキュリティプロトコル（TLS、[RFC2246]）、およびIPsec [RFC2401] - これらのプロトコルの文字制限を尊重しないと、それらを使用するために構築されたセキュリティツールに影響を与えます。
Failure may not be obvious. For example, in TLS, it is common usage for a server to display a certificate containing a domain name purporting to be the domain name of the server, which the client can then match with the server name he thought he used to reach the service.
失敗は明らかではないかもしれません。例えば、TLSでは、クライアントはその後、彼はサービスに到達するために使用されると思ったサーバー名と一致させることができ、サーバのドメイン名であることを主張するドメイン名を含む証明書を表示するには、サーバーのための一般的な使用です。
Unless comparison of domain names is properly defined, the client may either fail to match the domain name of a legitimate server, or match incorrectly the domain name of a server performing a man-in-the-middle attack. Either failure could enable attacks on systems that are now impossible or at least far more difficult.
ドメイン名の比較が適切に定義されていない限り、クライアントは正当なサーバーのドメイン名と一致しない、または正しくman-in-the-middle攻撃を実行するサーバーのドメイン名と一致してどちらか。どちらの障害は今不可能か、少なくともはるかに困難であり、システムへの攻撃を可能にすることができます。
It is therefore clear that, although there are many possible ways to assign internationalized names that are compatible with today's DNS (or a version that is easily-deployable in the near future), not all of them are compatible with the full range of necessary networking tools. When designing a solution for internationalization of domain names, the effects on the current Internet must be carefully evaluated. Some types of solutions proposed would, if put into effect immediately, cause Internet communications to fail in ways that would be hard to detect by and pose problems for those who deploy the new services, but also for those who do not; this would have the effect of cutting those who deploy them off from effective use of the Internet.
今日のDNS（または近い将来に簡単に展開可能であるバージョン）と互換性のある国際名前を割り当てるには、多くの可能な方法があるが、すべてではないそれらの必要なネットワーキングの全範囲と互換性がある、ということが明らかですツール。ドメイン名の国際化のためのソリューションを設計するとき、現在のインターネットへの影響を慎重に評価しなければなりません。提案されたソリューションの種類によっては、すぐに有効に入れた場合、インターネット通信をすることにより検出し、新しいサービスを展開する人のために問題を提起するのは難しいが、また、そうでない人のためになる形で失敗する原因となります。これは、インターネットの有効利用からそれらを展開する人をカットする効果を持っているでしょう。
The IDN WG has been identified as the appropriate forum for identifying and discussing solutions for such potential interoperability issues.
IDN WGは、このような潜在的な相互運用性の問題のためのソリューションを特定し、議論するための適切なフォーラムとして同定されています。
Experience with deployment of other protocols has indicated that it will take years before a new protocol or enhancement is used all over the Internet. So far, the IDN WG has benefited from proposed solutions from all quarters, including organizations hoping to provide services that address visible-name representation and registration -- continuing this process with the aim of getting a single, scalable and deployable solution to this problem is the only way to ensure the continued global interoperation that is the deserved expectation of all Internet users.
他のプロトコルの展開の経験は、新しいプロトコルまたは増強は全てインターネット上で使用される前に、それは何年もかかるだろうことを示しています。これまでのところ、IDN WGは、可視名の表現と登録を扱うサービスを提供することを望んで組織を含む各方面から提案されたソリューションから恩恵を受けている - この問題に、単一のスケーラブルで展開可能なソリューションをされて取得する目的で、このプロセスを継続しますすべてのインターネットユーザーの期待に値するで継続的なグローバルな相互運用性を確保するための唯一の方法。
In general, assignment and use of names does not raise any special security problems. However, as noted above, some existing security mechanisms are reliant on the current specification of domain names and may not be expected to work, as is, with Internationalized domain names. Additionally, deployment of non-standard systems (e.g., in response to current pressures to address national or regional characterset representation) might result in name strings that are not globally unique, thereby opening up the possibility of "spoofing" hosts from one domain in another, as described in [RFC2826].
一般的には、名前の割り当てと使用は、特別なセキュリティ上の問題を提起しません。しかしながら、上述のように、いくつかの既存のセキュリティメカニズムは、ドメイン名の現在の仕様に依存しており、国際化ドメイン名で、そのまま、動作するように期待されなくてもよいです。また、非標準システムの展開、グローバルに一意でない名前の文字列になる場合があります（現在の圧力に応じて、例えば、国や地域のキャラクタ表現に対処するために）、それによって別であるドメインからの「なりすまし」のホストの可能性を開きます、[RFC2826]に記載されているように。
This document is the outcome of the joint effort of the members of the IAB. Additionally, valuable remarks were provided by Randy Bush, Patrik Faltstrom, Ted Hardie, Paul Hoffman, and Mark Kosters.
このドキュメントは、IABのメンバーの共同の努力の成果です。また、貴重な発言はランディブッシュ、パトリックFaltstrom、テッドハーディー、ポール・ホフマン、そしてマーク・Kostersによって提供されました。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC821]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1982年8月。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念および機能"、STD 13、RFC 1034、1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, November 1989.
[RFC1123]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年11月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2409] Harkins, D and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンズ、DおよびD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
[RFC2459] Housley氏、R.、フォード、W.、ポーク、W.およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書とCRLプロファイル"、RFC 2459、1999年1月。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J. and M. Rose, "Textual Conventions for SMIv2", RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.とM.ローズ、 "SMIv2のためのテキストの表記法"、RFC 2579、1999年4月。
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999.
[RFC2622] Alaettinoglu、C.、Villamizar、C.、Gerich、E.、Kessens、D.、マイヤー、D.、ベイツ、T.、Karrenberg、D.およびM.テルプストラ、「ルーティングポリシー仕様言語（RPSL） 」、RFC 2622、1999年6月。
[RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000.
[RFC2826] IAB、 "ユニークなDNS根のIAB技術コメント"、RFC 2826、2000年5月。
Internet Architecture Board
インターネットアーキテクチャ委員会
EMail: iab@iab.org
メールアドレス：iab@iab.org
Membership at time this document was completed:
このドキュメントが完成した時点で会員：
Harald Alvestrand Ran Atkinson Rob Austein Brian Carpenter Steve Bellovin Jon Crowcroft Leslie Daigle Steve Deering Tony Hain Geoff Huston John Klensin Henning Schulzrinne
ハラルドAlvestrandはアトキンソンロブAusteinとブライアン・カーペンタースティーブBellovin氏ジョンクロウクロフトレスリーDaigle氏スティーブデアリングトニーハインジェフ・ヒューストンジョン・クレンシンヘニングSchulzrinneと蘭
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。