この文書はRFC2825の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
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.
インターネット・プロトコルを「国際化」する仕事の目的は、すべてのイン
ターネットユーザに自分の言語と標準文字で自己表現をし、名前を書き、ネッ
トワークを案内する能力を提供することを含みます。これは電子メールアド
レスと今日のワールドワイドウェブでローカル情報に使うＵＲＬの多くなど
で見えるドメイン名に影響を与えます。しかしながら、ドメイン名が国境を
越えてインターネット・プロトコルで使われます。これらのサービスは世界
的に相互運用できるか、ローカル境界線でネットワークの要素が孤立する危
険を冒さなければなりません。この種の孤立は人々の間の通信に影響するだ
けでなく、国際的なスケールでの電子通商や距離学習や他の活動を妨げ、そ
れで経済発展を遅らせます。
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.
ドメイン名を国際化するいくつかの提案がありますが、目に見える名前表現
を扱う間に、どれが相互運用とグローバル到達が可能か決定をしなければな
りません。いくつかは明らかにそうでありません。特定の提案を再検討は、
全てのインターネットユーザが当然期待するグローバルネットワーク相互運
用を考えて評価を行う仕事をする、ＩＥＴＦの国際化ドメイン名（ＩＤＮ）
作業班の仕事なので、この文書は再検討を試みません。
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.
この文書はインターネットアーキテクチャ委員会による宣言です。ドメイン
名の国際化が直面するのはプロトコル仕様ではなく、体系の問題の限界を明
確にする試みです。
1. A Definition of Success
1. 成功の定義
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.
国際化ドメイン名（ＩＤＮ）作業班は、インターネットのグローバル機能を
支援するプロトコルで、言語表現機能を国際化するＩＥＴＦの継続的包括的
な努力の１つの要素です。
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.
おおざっぱな総意の、実行コードと、体系の完全性と、インターネットのグ
ローバルな安定性を保証することについての興味原則から、ＩＡＢは（ＩＤ
Ｎ）作業班に提案された全ての解決策は、個別の技術的な特徴からだけでな
く、インターネットの既存の標準と運用とエンドユーザへの全体的な影響か
ら提案された解決策を評価しなければならないことを強調します：解決策は
たとえそれがローカルな問題を解くように思われるとしても、ユーザをグロー
バルな近隣からより隔離してはなりません。ある場合には、既存のプロトコ
ルは許されている文字に限界があり、他の場合インターネットのコアのプロ
トコルの実装（個別の組織を越えて）が実際は標準のすべての必要なオプショ
ンを実装していませんでした。
2. Technical Challenges within the Domain Name System (DNS)
2. ドメインネームシステム（ＤＮＳ）の技術的挑戦
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.
多くの技術的な点で、ＩＤＮの仕事は伝統的に英語文字に限定されていたテ
キストの要素を多数の文字セット表現を可能にする他の努力と異なっていま
せん。
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.
挑戦の１つの面は、ユーザがＤＮＳで欲しい名前を表現する方法を、明確に、
技術的に実行可能で、名前が常に同じことを意味することを保証する方法、
決める事です。いくつかの提案がこれらの問題を扱うために提案されました。
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.
これらの問題はＩＤＮ ＷＧの進化する要求条件文書ドラフトでより詳細に
概説されています；これ以上の論議はＷＧとその文書に任せます。
3. Integrating with Current Realities
3. 現在の現実に融け込むこと
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.
にもかかわらず、ＩＤＮ作業班が直面した問題は複雑であり、インターネッ
トの他の運用上の要素に複雑に絡んでいます。提案された解決策の評価での
鍵は、完全指定ドメイン名[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.
これらは秘儀や一時的な懸念ではありません。ある特定の問題がすでにＩＤ
Ｎ ＷＧの努力の一部として識別されました。これらは次を含みます（全部
ではありません）。
3.1 Domain Names and E-mail
3.1 ドメイン名と電子メール
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.
ＩＤＮ ＷＧの必要条件文書ドラフトで示されるように、問題はＤＮＳ使用法
の標準化を越えてます。電子メールは長い間インターネットの大部分で使わ
れ、そして最も重要なアプリケーションの１つです。インターネット電子メー
ルは、いろいろなローカルや専有のメールシステムのユーザが通信をするの
を可能にする橋として用いられます。その使用を定義するプロトコル（例え
ば、 ＳＭＴＰ[RFC821, RFC822]やＭＩＭＥ[RFC2045]）がＤＮＳ仕様で許す
全ての文字を許可していません。ある特定の文字がこれらの仕様書の電子メー
ルアドレスドメイン部で許されません。あるメイラーが、これらの仕様書に
準じて作られて、メールのアドレスに非ＡＳＣＩＩドメイン名があると失敗
することが知られています−廃棄や転送ミスやメールを破壊するなど。それ
で、ただ国際化ドメイン名に単純に切り替えるのは可能ではなく、世界中の
サーバの大部分が更新されるまでグローバルな電子メールが働き続けること
を期待されます。
3.2 Domain Names and Routing
3.2 ドメイン名とルーティング
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.
より低いレベルで、ルーティングポリシー仕様（ＲＰＬＳ）[RFC2622]は「命
名オブジェクト」を利用して − そしてより古い標準のオブジェクトを命名
制限を継承します（同様の電子メールアドレス制限は[RFC822]、ホスト名は
[RFC1034] ）。これはルーティングレジストリとそれらのプロトコルが最新
にされるまで、国際化ドメイン名を利用してネットワーク記述を登録するか
得ることが可能ではないことを意味します。
3.3 Domain Names and Network Management
3.3 ドメイン名とネットワーク管理
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.
同じく、シンプル・ネットワーク・マネジメント・プロトコル（ＳＮＭＰ）
は[RFC2579]で定義されたテキスト表現を使います。その仕様書がＵＴＦ−８
ベースのドメイン名を考慮するが、ＳＮＭＰに従ってソフトウェアを構築す
るための使われているソフトウェアライブラリの利用されている実装の非公
式の調査でほとんどがそれを実装していないという事実が暴露されました。
This may cause inability to enter or display correct data in network
management tools, if such names are internationalized domain names.
もしこのような名前が国際化ドメイン名であるなら、これはネットワーク管
理ツールで正しいデータを入力するか表示することが不可能かもしれません。
3.4 Domain Names and Security
3.4 ドメイン名とセキュリティ
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.
インターネット公開鍵技術のクリティカルな要素（ＰＫＩＸ[RFC2459]、ＩＫ
Ｅ[RFC2409]）が強くサーバ識別子（ホスト名、あるいは完全指定ドメイン名）
とユーザ（電子メールアドレス）に依存します。これらのプロトコルの文字
制限を重んずることの障害は、それらを使う−輸送レイヤセキュリティプロ
トコル(TLS, [RFC2246])とＩＰｓｅｃ[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.
失敗は明白でないかもしれません。例えば、ＴＳＬで、サーバがサーバドメ
イン名だと主張するドメイン名を含む証明書を表示し、クライアントがサー
バ名を彼がサービスに達するために使ったと思ったサーバ名と比較するのが、
一般的な使用方法です。
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.
ドメイン名の比較が正確に定義されないなら、クライアントは正しいサーバ
ドメイン名の比較に失敗するか、あるいは間違って中間者攻撃を行っている
サーバのドメイン名と一致するかもしれません。いずれの失敗も現在は不可
能であるか少なくとも難しいシステムに対する攻撃を可能にすることができ
ます。
4. Conclusion
4. 結論
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.
今日のＤＮＳ（あるいは近い将来容易に配置されるバージョン）と互換性が
ある国際化名の割り当ての多くの可能な方法があるけれども、それらのすべ
てが必要なネットワーキングツールの完全な範囲と両立できるわけではない
ことは、それ故に明確です。ドメイン名の国際化のための解決策を設計する
時、現在のインターネットに対する効果は慎重に評価されなくてはなりませ
ん。提案された解決策のある種類は、もしすぐに実施されるなら、新しいサー
ビスを配置する人達とそうでない人達にインターネット通信を検出の難しく
見せかけの方法で失敗させます；これはそれらを配置する人たちをインター
ネットの効率的な使用から隔離する効果を持つでしょう。
The IDN WG has been identified as the appropriate forum for
identifying and discussing solutions for such potential
interoperability issues.
ＩＤＮ ＷＧはこのような可能性がある互換性問題の解決策を認識し議論する
適切な討論場所と認知されました。
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.
他のプロトコルの配置の経験は、新しいプロトコルあるいは拡張がインター
ネット中でいたる所に使われる前に、何年もを要するであろうことを示しま
した。これまでのところ、ＩＤＮ ＷＧは、目に見える名前表現の登録を扱
うサービスを供給することを望んでいる組織を含めて、すべての方面から提
案された解決策から利益を得ました−このこの問題に対する１つのスケーラ
ブルで配置可能な解決策を得る処理を続けることは、すべてのインターネッ
トユーザの期待に値する継続的でグローバルな相互運用を保証する唯一の方
法です。
5. Security Considerations
5. セキュリティの考察
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]で記述されるように、
ドメイン間で「なりすまし」ホストの可能性を広げます。
6. Acknowledgements
6. 謝辞
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.
この文書はＩＡＢのメンバーの共同の努力の結果です。さらに、貴重な発言
がRandy BushとPatrik FaltstromとTed HardieとPaul HoffmanとMark Kosters
によって供給されました。
7. References
7. 参考文献
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts -- Application
and Support", STD 3, RFC 1123, November 1989.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2409] Harkins, D and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC 2459, January 1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.
and M. Rose, "Textual Conventions for SMIv2", RFC 2579,
April 1999.
[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.
[RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC
2826, May 2000.
8. Author's Address
8. 著者のアドレス
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
9. Full Copyright Statement
9. 著作権表示全文
Copyright (C) The Internet Society (2000). 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.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。