[要約] 要約：RFC 2825は、国際化（I18N）、ドメイン名、および他のインターネットプロトコルに関連する問題についての詳細な説明を提供しています。 目的：このRFCの目的は、国際化に関連する問題を理解し、ドメイン名と他のインターネットプロトコルの相互運用性を向上させるためのガイドラインを提供することです。
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
もつれたウェブ：i18n、ドメイン名、およびその他のインターネットプロトコルの問題
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.
Copyright（c）The Internet Society（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の多くに影響を与えます。ただし、ドメイン名は、国境を越えて使用されるインターネットプロトコルで使用されます。これらのサービスは、世界中で相互運用する必要があります。または、ネットワークのコンポーネントをロケール境界に沿って互いに分離するリスクがあります。このタイプの孤立は、人々の間のコミュニケーションだけでなく、eコマース、遠隔学習、および国際規模でのその他の活動に効果的に参加する機会を妨げる可能性があり、それによって経済発展を遅らせます。
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.
課題の1つの側面は、ユーザーが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使用量の標準化を超えています。電子メールは、長い間、インターネットで最も使用され、最も重要なアプリケーションの1つです。インターネット電子メールは、さまざまなローカルおよび独自のメールシステムのユーザーが通信できるブリッジとしても使用されます。その使用を定義する標準プロトコル（例：SMTP [RFC821、RFC822]およびMIME [RFC2045]）は、DNS仕様で許可されているすべての文字を許可しません。特定の文字は、これらの仕様の電子メールアドレスドメイン部分では許可されていません。これらの仕様を遵守するために構築された一部のメーラーは、メールを廃棄、誤って、または損害を与えることにより、アドレスに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.
低レベルでは、ルーティングポリシー仕様言語（RPLS）[RFC2622]は「名前付きオブジェクト」を使用し、同じ電子メールアドレスの制限に対してオブジェクトの命名制限（[RFC822]を継承します[RFC1034]ホスト名）。これは、ルーティングレジストリとそのプロトコルが更新されるまで、国際化されたドメイン名を使用してネットワークの説明を入力または取得することはできないことを意味します。
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]）の重要なコンポーネントは、サーバー（ホスト名、または完全に資格のあるドメイン名）とユーザー（電子メールアドレス）の識別に大きく依存しています。これらのプロトコルのキャラクターの制限を尊重しないと、それらを使用するように構築されたセキュリティツール（TLS、TLS、[RFC2246]）、およびIPSEC [RFC2401]が2つの名前を付けます。
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.
ドメイン名の比較が適切に定義されていない限り、クライアントは正当なサーバーのドメイン名と一致しないか、中間の攻撃を実行するサーバーのドメイン名を誤って一致させない場合があります。いずれかの失敗は、現在不可能なシステムへの攻撃を可能にする可能性があるか、少なくともはるかに困難です。
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のメンバーの共同努力の結果です。さらに、Randy Bush、Patrik Faltstrom、Ted Hardie、Paul Hoffman、Mark Kostersによって貴重な発言が提供されました。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC821] Postel、J。、「Simple Mail Transfer Protocol」、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] Crocker、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] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年11月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2409] Harkins, D and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、DおよびD. Carrel、「The Internet Key Exchange（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] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「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.、Ford、W.、Polk、W。and D. Solo、「インターネット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.、Perkins、D.、Schoenwaelder、J.、Case、J。and M. Rose、「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.、Meyer、D.、Bates、T.、Karrenberg、D。、およびM. Terpsstra、「ルーティングポリシー仕様言語（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
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
ハラルド・アルベスランド・ラン・ラン・アトキンソン・ロブ・アウスタイン・ブライアン・カーペンター・スティーブ・ベロヴィン・ジョン・クロフト・レスリー・デイグル・ディーグ・ディアリング・トニー・ヘイン・ヘイン・ハストン・ジョン・クレンシン・ヘニング・シュルツリン
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。