RFC4290 日本語訳
4290 Suggested Practices for Registration of Internationalized DomainNames (IDN). J. Klensin. December 2005. (Format: TXT=71115 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Klensin Request for Comments: 4290 December 2005 Category: Informational
Klensinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4290 2005年12月のカテゴリ: 情報
Suggested Practices for Registration of
Internationalized Domain Names (IDN)
国際化ドメイン名の登録のための提案された習慣(IDN)
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 (2005).
Copyright(C)インターネット協会(2005)。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFはどんな目的と発行するという決定がIETF仕事との闘争のためのIESGレビューは別としてIETFレビューに基づいていないというメモのためにもこのRFCのフィットネスに関するどんな知識も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 詳しい情報に関してRFC3932を見てください。
Abstract
要約
This document explores the issues in the registration of internationalized domain names (IDNs). The basic IDN definition allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar- looking names. To avoid this confusion, the IDN registration process must impose rules that disallow some otherwise-valid name combinations. This document suggests a set of mechanisms that registries might use to define and implement such rules for a broad range of languages, including adaptation of methods developed for Chinese, Japanese, and Korean domain names.
このドキュメントは国際化ドメイン名(IDNs)の登録における問題を探ります。 基本的なIDN定義はドメイン名で非常に多くの可能なキャラクタを許容します、そして、この豊かは同様の見る名に関して重大なユーザ混乱につながるかもしれません。 この混乱を避けるために、IDN登録手続はいくつかのそうでなければ、有効な名前組み合わせを禁じる規則を課さなければなりません。 このドキュメントは登録が広範囲な言語のためにそのような規則を定義して、実行するのに使用するかもしれない1セットのメカニズムを示します、中国の、そして、日本の、そして、韓国のドメイン名のために開発された方法の適合を含んでいて。
Klensin Informational [Page 1] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[1ページ]のRFC4290IDN登録は2005年12月に練習されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. The Nature and Status of these Recommendations .............4
1.3. Terminology ................................................5
1.3.1. Languages and Scripts .................................5
1.3.2. Characters, Variants, Registrations, and Other
Issues ................................................6
1.3.3. Confusion, Fraud, and Cybersquatting ..................9
1.4. A Review of the JET Guidelines .............................9
1.4.1. JET Model .............................................9
1.4.2. Reserved Names and Label Packages ....................10
1.5. Languages, Scripts, and Variants ..........................11
1.5.1. Languages versus Scripts .............................11
1.5.2. Variant Selection ....................................13
1.6. Variants are not a Universal Remedy .......................14
1.7. Reservations and Exclusions ...............................14
1.7.1. Sequence Exclusions for Valid Characters .............14
1.7.2. Character Pairing Issues .............................15
1.8. The Registration Bundle ...................................15
1.8.1. Definitions and Structure ............................15
1.8.2. Application of the Registration Bundle ...............16
2. Some Implications of This Approach .............................17
3. Possible Modifications of the JET Model ........................18
4. Conclusions and Recommendations About the General Approach .....18
5. A Model Table Format ...........................................19
6. A Model Label Registration Procedure: "CreateBundle" ...........20
6.1. Description of the CreateBundle Mechanism .................21
6.2. The "no-variants" Case ....................................22
6.3. CreateBundle and Nameprep Mapping .........................22
7. IANA Considerations ............................................23
8. Internationalization Considerations ............................24
9. Security Considerations ........................................24
10. Acknowledgements ..............................................25
11. Informative References ........................................26
1. 序論…3 1.1. バックグラウンド…3 1.2. これらのRecommendationsのネイチャーとStatus…4 1.3. 用語…5 1.3.1. 言語とスクリプト…5 1.3.2. キャラクター、異形、登録証明書、および他の問題…6 1.3.3. 混乱、詐欺、およびサイバースクワッティング…9 1.4. ジェットガイドラインのレビュー…9 1.4.1. ジェットモデル…9 1.4.2. 名前とラベルパッケージを予約します…10 1.5. 言語、スクリプト、および異形…11 1.5.1. 言語対スクリプト…11 1.5.2. 異形選択…13 1.6. 異形はUniversal Remedyではありません…14 1.7. 予約と除外…14 1.7.1. 有効なキャラクターのための系列除外…14 1.7.2. キャラクター組み合わせ問題…15 1.8. 登録バンドル…15 1.8.1. 定義と構造…15 1.8.2. 登録バンドルのアプリケーション…16 2. このいくつかの含意にアプローチします…17 3. ジェットの可能な変更はモデル化されます…18 4. 司令官に関する結論と推薦にアプローチします…18 5. モデルテーブル形式…19 6. モデルラベル登録手順: "CreateBundle"…20 6.1. CreateBundleメカニズムの記述…21 6.2. 「異形がありません」ケース…22 6.3. CreateBundleとNameprepマッピング…22 7. IANA問題…23 8. 国際化問題…24 9. セキュリティ問題…24 10. 承認…25 11. 有益な参照…26
Klensin Informational [Page 2] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[2ページ]のRFC4290IDN登録は2005年12月に練習されます。
1. Introduction
1. 序論
1.1. Background
1.1. バックグラウンド
The IDNA (Internationalized Domain Names in Applications) specification [RFC3490] defines the basic model for encoding non- ASCII strings in the DNS. Additional specifications [RFC3491] [RFC3492] define the mechanisms and tables needed to support IDNA. As work on these specifications neared completion, it became apparent that it would be desirable for registries to impose additional restrictions on the names that could actually be registered (e.g., see [IESG-IDN] and [ICANN-IDN]) to reduce potential confusion among characters that were similar in some way. This document explores these IDN (international domain name) registration issues and suggests a set of mechanisms that IDN registries might use.
IDNA(ApplicationsでDomain Namesを国際的にする)仕様[RFC3490]は、DNSで非ASCIIのストリングをコード化するために基本型を定義します。 追加仕様[RFC3491][RFC3492]はメカニズムを定義します、そして、テーブルはIDNAを支持する必要がありました。 これらの仕様に対する仕事が完成に近づいたとき、登録が何らかの方法で同様であったキャラクタの中で潜在的混乱を抑えるために実際に登録できた(例えば、[IESG-IDN]と[ICANN-IDN]を見ます)名前に追加制限を課すのが、望ましいだろうというのは明らかになりました。 このドキュメントは、これらのIDN(多言語ドメイン)登録問題を探って、IDN登録が使用するかもしれない1セットのメカニズムを示します。
Registration restrictions are part of a long tradition. For example, while the original DNS specifications [RFC1035] permitted any string of octets in a DNS label, they also recommended the use of a much more restricted subset. This subset was derived from the much older "hostname" rules [RFC952] and defined by the "LDH" convention (for the three permitted types of characters: letters, digits, and the hyphen). Enforcement of this restricted subset in registrations was the responsibility of the registry or domain administrator. The definition of the subset was embedded in the DNS protocol itself, although some applications protocols, notably those concerned with electronic mail, did impose and enforce similar rules.
登録制限は長い伝統の一部です。 例えば、また、当初のDNS仕様[RFC1035]がDNSラベルで八重奏のどんなストリングも可能にしていた間、彼らは非常にさらに制限された部分集合の使用を推薦しました。 この部分集合は、"LDH"コンベンションによってはるかに古い「ホスト名」規則[RFC952]から得られて、定義されました(3がキャラクタ: 手紙、ケタ、およびハイフンのタイプを可能にしたので)。 登録証明書における、この制限された部分集合の実施は登録かドメイン管理者の責任でした。 部分集合の定義はDNSプロトコル自体に埋め込まれました、いくつかのアプリケーションプロトコル(著しく電子メールに関するもの)が、同様の規則を課して、実施しましたが。
If there are no constraints on registration in a zone, people can register characters that increase the risk of misunderstandings, cybersquatting, and other forms of confusion. A similar situation existed even before the introduction of IDNA, as exemplified by domain names such as example.com and examp1e.com (note that the latter domain contains the digit "1" instead of the letter "l").
登録に規制が全くゾーンになければ、人々は誤解、サイバースクワッティング、および他の形式の混乱の危険を増加させるキャラクタを示すことができます。 同様の状況はIDNAの導入の前にさえ存在しました、example.comやexamp1e. comなどのドメイン名によって例示されるように(後者のドメインがケタを含むことに注意してください、「文字「l」の代わりに1インチ)」
For non-ASCII names (so-called "internationalized domain names" or "IDNs"), the problem is more complicated. In the earlier situation that led to the LDH (hostname) rules, all protocols, hosts, and DNS zones used ASCII exclusively in practice, so the LDH restriction could reasonably be applied uniformly across the Internet. Support for IDNs introduces a very large character repertoire, different geographical and political locations, and languages that require different collections of characters. The optimal registration restrictions are no longer a global matter; they may be different in different areas and, hence, in different DNS zones.
非ASCII名(いわゆる「国際化ドメイン名」か「IDNs」)において、問題は、より複雑です。 LDH(ホスト名)規則につながった以前の状況で、すべてのプロトコル、ホスト、およびDNSゾーンが排他的な習慣にASCIIを使用したので、インターネットの向こう側に一様に合理的にLDH制限を当てはまることができました。 IDNsのサポートは非常に大きいキャラクタレパートリー、異なった地理的で政治上の位置、およびキャラクタの異なった収集を必要とする言語を紹介します。 最適の登録制限はもうグローバルな問題ではありません。 それらは異なった領域としたがって異なったDNSゾーンにおいて異なっているかもしれません。
Klensin Informational [Page 3] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[3ページ]のRFC4290IDN登録は2005年12月に練習されます。
For some human writing systems, there are characters and/or strings that have equivalent or near-equivalent usages. If a name can be registered with such a character or string, the registry might want to automatically associate all of the names that have the same meaning with the registered name. The registry might also decide whether the names that are associated with, or generated by, one registration should, as a group or individually, go into the zone or should be blocked from registration by different parties.
いくつかの人間の書記体系のために、同等であるか同等物の用法を持っているキャラクタ、そして/または、ストリングがあります。 そのようなキャラクタかストリングに名前を登録できるなら、登録は自動的に同じ意味を持っている名前のすべてを登録名に関連づけたがっているかもしれません。 また、登録が決めるかもしれない、関連しているか、または発生している名前、ある登録が妨げるべきであり、aとして、分類してくださいか、または個別に、ゾーンを調べるべきであるか、登録と異なったパーティーによって妨げられるべきです。
To date, the best-developed system for handling registration restrictions for IDNs is the JET Guidelines for Chinese, Japanese, and Korean [RFC3743], the so-called "CJK" languages. The JET Guidelines are limited to the CJK languages and, in particular, to their common script base. Those languages are also the best-known and most widely-used examples of writing systems constructed on "ideographic" or "pictographic" principles. This document explores the principles behind the JET guidelines. It then examines some of the issues that might arise in adapting them to alphabetic languages, i.e., to languages whose characters primarily represent sounds rather than meanings.
これまで、IDNsのための取り扱い登録制限のもっとも発達した系は中国語、日本語、および韓国語[RFC3743](いわゆる"CJK"言語)のためのJET Guidelinesです。 JET GuidelinesはCJK言語と、そして、特にそれらの一般的なスクリプトベースに制限されます。 また、それらの言語も最もよく知られています、そして、大部分は広く「表意文字」の、または、「pictographicな」原則で構成された書記体系に関する例を使用しました。 このドキュメントはJETガイドラインの後ろで原則を探ります。 次に、それはアルファベット言語にそれらを適合させる際に起こるかもしれない問題のいくつかを調べます、すなわち、キャラクタが主として意味よりむしろ音を表す言語に。
This document describes five things:
このドキュメントは5つのものについて説明します:
1. The general background and considerations for non-ASCII scripts
in names.
1. 名前の非ASCIIスクリプトのための一般的なバックグラウンドと問題。
2. Suggested practices for describing character variants.
2. キャラクタ異形について説明するために習慣を示しました。
3. A method for using a zone's character variants to determine which
names should be associated with a registration.
3. どの名前を決定するかにゾーンのキャラクタ異形を使用するための方法は登録に関連しているべきです。
4. A format for publishing a zone's table of character variants;
Such tables are referred to below simply as "language tables" or
simply "tables".
4. ゾーンのキャラクタ異形のテーブルを発行するための形式。 そのようなテーブルは単に「言語テーブル」か単に「テーブル」として以下と呼ばれます。
5. A model algorithm for name registration given the presence of
language tables.
5. 言語テーブルの存在に与えられた名前登録のためのモデルアルゴリズム。
1.2. The Nature and Status of these Recommendations
1.2. これらのRecommendationsのネイチャーとStatus
The document makes recommendations for consideration by registries and, where relevant, by those who coordinate them, and by those who use their services. None of the recommendations are intended to be normative. Instead, the intent of the document is to illustrate a framework for developing variations to meet the needs of particular registries and their processing of particular languages. Of course, if registries make similar decisions and utilize similar tools, costs
ドキュメントは登録のそばで考慮のための推薦状をします、そして、関連しているところでは、それらを調整して、それらでそれらでだれが彼らのサービスを利用しますか? 推薦のどれかが規範的であることを意図しません。 代わりに、ドキュメントの意図は展開している変化が特定の登録の需要と彼らの特定の言語の処理を満たすように枠組みを例証することです。 もちろんコスト登録が同様の決定をして、同様のツールを利用するなら
Klensin Informational [Page 4] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[4ページ]のRFC4290IDN登録は2005年12月に練習されます。
and confusion may be reduced -- both between registries and for users and registrars who have relationships with more than one domain.
そして、混乱は抑えられるかもしれません--登録の間と、そして、1つ以上のドメインとの関係を持っているユーザと記録係両方。
Just as the JET Guidelines contain some suggestions that may not be applicable to alphabetic scripts, some of the suggestions here, especially the more specific ones, may be applicable to some scripts and not others.
ちょうどJET Guidelinesがアルファベットスクリプトに適切でないかもしれないいくつかの提案を含むとき、ここでの提案のいくつか(特に特定のもの)が他のものではなく、いくつかのスクリプトに適切であるかもしれません。
1.3. Terminology
1.3. 用語
1.3.1. Languages and Scripts
1.3.1. 言語とスクリプト
This document uses the term "language" in what may be, to many readers, an odd way. Neither this specification, nor IDNA, nor the DNS are directly concerned with natural language, but only with the characters that make up a given label. In some respects, the term "script", used in the character coding community for a collection of characters, might be more appropriate. However, different subsets of the same script may be used with different languages, and the same language may be written using different characters (or even completely different scripts) in different locations, so "script" is not precisely correct either.
このドキュメントは多くの読者には変な方法であるかもしれないものに「言語」という用語を使用します。 この仕様もIDNA、およびDNSも直接そうではありません。自然言語にもかかわらず、キャラクタだけに、それが与えられたラベルを作ることを心配しています。 ある点で、「スクリプト」というキャラクタの収集にキャラクタコード化社会で使用される用語は、より適切であるかもしれません。 しかしながら、同じスクリプトの異なった部分集合が異なった言語と共に使用されるかもしれなくて、同じ言語が別の場所で異なったキャラクタ(または、完全に異なったスクリプトさえ)を使用することで書かれているかもしれないので、「スクリプト」は正確に正しくはありません。
Long-standing confusion has also resulted from the fact that most scripts are, informally at least, named after one of the languages written in them. "Chinese" describes both a language and a collection of characters that are also used in writing Japanese, Korean, and, at least historically, some other languages. "Latin" describes a language, the characters used to write that language, and, often, characters used to write a number of contemporary languages that are derived from or similar to those used to write the Latin language. The script used to write the Arabic language is called "Arabic", but it is also used (typically with some additions or deletions) to write a number of other languages. Situations in which a script has a clearly-defined name that is independent of the name of a language are the exception, rather than the rule; examples include Hangul, used to write Korean, Katakana and Hiragana, used to write Japanese, and a few others. Some scholars have historically used "Roman" or "Roman-derived" for the script in an attempt to distinguish between a script and the Latin language.
また、長年の混乱はほとんどのスクリプトが少なくとも非公式にそれらに書かれた言語の1つにちなんで名付けられるという事実から生じました。 「中国語」はまた、日本語、韓国語、およびある他の少なくとも歴史的に言語を書く際に使用される言語とキャラクタの収集の両方について説明します。 多くの現代の言語にそれを書くのに使用されるキャラクタは、しばしば、ラテン語を書くのに使用されるものと、「ラテン」は言語を説明して、キャラクタは以前はよくその言語を書いていて、派生しているか、または同様です。 アラビアの言語を書くのに使用されるスクリプトは「アラビアである」と呼ばれますが、また、それは、他の多くの言語を書くのに使用されます(通常いくつかの追加か削除で)。 スクリプトが言語の名前から独立している明確に定義された名前を持っている状況は規則よりむしろ例外です。 例は韓国語、Katakana、およびHiraganaに書くのに使用される日本人、および数人の他のものに書くのにおいて中古のハングルを含んでいます。 学者の中にはスクリプトにスクリプトとラテン語を見分ける試みに「ローマ」か「ローマに派生すること」を歴史的に使用した人もいました。
The term "language" is therefore used in this document in the informal sense of a written language and is defined, for this purpose, by the characters used to write it, i.e., as a language- specific subset of a script. In this context, a "language" is defined by the combination of a code (see Section 1.4.1) and an authority that has chosen to use that code and establish a character-listing for it. Authorities are normally TLD (top-level
「言語」という用語は、したがって、本書では文語の非公式の意味で使用されて、定義されます、このために、それを書くのに使用されるキャラクタで、すなわち、スクリプトの言語の特定の部分集合として。 このような関係においては、「言語」はコード(セクション1.4.1を見る)の組み合わせとそのコードを使用して、それのためにキャラクタリストを設立するのを選んだ権威によって、定義されます。 通常、当局がTLDである、(トップレベル
Klensin Informational [Page 5] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[5ページ]のRFC4290IDN登録は2005年12月に練習されます。
domain) registries; see Section 7 and [IANA-language-registry]. However, it is expected that TLD registries will find appropriate experts and that advice from language and script experts selected by international neutral bodies will also become part of the registration system. In addition, as discussed below in Section 7, registries may conclude that the best interests of registrants, stakeholders, and the Internet community would be served by constructing "language tables" that mix scripts and characters in ways that conform to no known language. Conventions should be developed for such registrations that do not misleadingly reflect specific language codes.
ドメイン) 登録。 セクション7と[IANA言語登録]を見てください。 しかしながら、TLD登録が適切な専門家を見つけて、また、専門家が国際的な中立ボディーで選択した言語とスクリプトからのアドバイスが登録制の一部になると予想されます。 さらに、セクション7で以下で議論するように、登録は、知られている言語がないのに従う方法でスクリプトとキャラクタを混ぜる「言語テーブル」を組み立てることによって記入者、利害関係者、およびインターネットコミュニティの利益のために役立たれていると結論を下すかもしれません。 コンベンションは誤解させて特定の言語コードを反映しないそのような登録証明書のために発展するべきです。
1.3.2. Characters, Variants, Registrations, and Other Issues
1.3.2. キャラクター、異形、登録証明書、および他の問題
1. Characters in this document are specified by their Unicode
codepoints in U+xxxx format, by their official names, or both.
1. キャラクターはU+xxxx形式におけるそれらのユニコードcodepoints、それらの正式名称、または両方によって本書では指定されます。
2. The following terms are used in this document.
2. 次の用語は本書では使用されます。
* String
* ストリング
A "string" is an sequence of one or more characters.
「ストリング」は1つ以上のキャラクタの系列です。
* Base Character
* 基本文字
This document discusses characters that may have equivalent or
near-equivalent characters or strings. A "base character" is
a character that has zero or more equivalents. In the JET
Guidelines, base characters are referred to as "valid
characters". In a table with variants, as described in
Section 5, the base characters occupy the first column.
Normally (and always, if the recommendation of Section 6.3 is
adopted), the base characters will be the characters that
appear in registration requests from registrants; any other
character will invalidate the registration attempt.
このドキュメントは同等であるか同等物のキャラクタかストリングを持っているかもしれないキャラクタについて議論します。 「基本文字」はゼロを持っているキャラクタであるか以上が同等物です。 JET Guidelinesでは、基本文字は「有効なキャラクタ」と呼ばれます。 異形があるテーブルでは、セクション5で説明されるように、基本文字は最初のコラムを占領します。 通常(セクション6.3の推薦がいつも採用されるなら)、基本文字は登録要求に記入者から現れるキャラクタになるでしょう。 いかなる他のキャラクタも登録試みを無効にするでしょう。
* Native Script
* 固有のスクリプト
Native script is the form in which the relevant string would
normally be represented. For example, it might use Lower
Slobbovian characters and the glyphs normally used to write
them. It would not be punycode as a presentation form.
固有のスクリプトは通常、関連ストリングが表されるフォームです。 例えば、Lower Slobbovianキャラクタを使用するかもしれません、そして、通常、glyphsは以前はよく彼らを書いていました。 それは表示形としてpunycodeでないでしょう。
* Variant Characters/Strings
* 異形キャラクター/ストリング
The "variant(s)" are character(s) and/or string(s) that are
treated as equivalent to the base character. Note that these
might not be exactly equivalent characters; a particular
「異形」は、基本文字と同等物として扱われるキャラクタ、そして/または、ストリングです。 これらがまさに同等なキャラクタでないかもしれないことに注意してください。 事項
Klensin Informational [Page 6] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[6ページ]のRFC4290IDN登録は2005年12月に練習されます。
original character may be a base character with a mapping to a
particular variant character, but that variant character may
not have a mapping to the original base character. Indeed,
the variant character may not appear in the base character
list, and hence may not be valid for use in a registration.
Usually, characters or strings to be designated as variants
are considered either equivalent or sufficiently similar (by
some registry-specific definition) that confusion between them
and the base character might occur.
オリジナルのキャラクタは特定の異形キャラクタへのマッピングをもっている基本文字であるかもしれませんが、その異形キャラクタはオリジナルの基本文字にマッピングを持っていないかもしれません。 本当に、異形キャラクタは、基本文字リストに現れないかもしれなくて、また使用には、したがって、登録で有効でないかもしれません。 通常、異形として任命されるキャラクタかストリングが同等であるか、または十分同様であると(何らかの登録特有の定義による)考えられて、それらと基本文字の間のその混乱が起こるかもしれないということです。
* Base Registration
* 基地の登録
The "base registration" is the single name that the registrant
requested from the registry. The JET Guidelines use the term
"label string" for this concept.
「ベース登録」は記入者が登録から要求したただ一つの名前です。 JET Guidelinesはこの概念に「ラベルストリング」という用語を使用します。
* Registered, Activated
* 登録されていて、活性です。
A label (or "name") is described as "registered" if it is
actually entered into a domain (i.e., into a zone file) by the
registry, so that it can be accessed and resolved using
standard DNS tools. The JET Guidelines describe a
"registered" label as "activated". However, some domains use
a slightly different registration logic in which a name can be
registered with the registrar (if one is involved) and with
the registry, but not actually entered into the zone file
until an additional activation or delegation step occurs.
This document does not make that distinction, but is
compatible with it.
それが実際に登録によってドメイン(すなわち、ゾーンファイルの中への)に入れられるなら、ラベル(または、「名前」)は「登録されている」と記述されます、標準のDNSツールを使用することでそれにアクセスして、決議できるように。 JET Guidelinesは「動かされる」ように「登録された」ラベルについて説明します。 しかしながら、いくつかのドメインが追加起動か代表団ステップが起こるまで、名前を記録係(1つが伴われるなら)と登録に登録されますが、実際にゾーンファイルの中に入れることができないわずかに異なった登録論理を使用します。 このドキュメントは、それを区別にしませんが、それと互換性があります。
As specified in the IDNA Standard, the name actually placed in
the zone file is always the internal ("punycode") form. There
is no provision for actually entering any other form of an IDN
into the DNS. It remains controversial, with different
registrars and registries having adopted different policies,
as to whether the registration, as submitted by the
registrant, is in the form of:
IDNA Standardで指定されるように、いつも実際にゾーンファイルに置かれた名前は内部の("punycode")フォームです。 実際にIDNのいかなる他のフォームもDNSに入れることへの支給が全くありません。 記入者で提出する登録が以下の形にあるかに関してそれは異なった記録係と登録が異なった方針を採って論議を呼んだままで残っています。
o The native-script name, either in UTF-8 or in some coding
specified by the registrar, or
o またはUTF-8かいくつかのコード化で記録係によって指定された固有のスクリプト名。
o the internal-form ("punycode") name, or
o または内部のフォーム("punycode")名。
o both forms of the name together, so that the registrar and
registry can verify the intended translation.
o 記録係と登録が意図している翻訳について確かめることができるための一緒にという名前の両方のフォーム。
Klensin Informational [Page 7] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[7ページ]のRFC4290IDN登録は2005年12月に練習されます。
If any of the approaches defined in this document is used, it
is almost certain to be necessary that the native-script form
of the requested string be available to the registry.
本書では定義されたアプローチのどれかが使用されているなら、要求されたストリングの固有のスクリプトフォームが登録に利用可能であることが必要であるのはほとんど確かです。
* Registration Bundle
* 登録バンドル
A "registration bundle" is the set of all labels that come
from expanding the base characters for a single name into
their variants. The presence of a label in a registration
bundle does not imply that it is registered. In the JET
Guidelines, a registration bundle is called an "IDN Package".
「登録バンドル」はただ一つの名前のために彼らの異形に基本文字を広げるのから来るすべてのラベルのセットです。 登録バンドルでのラベルの存在は、それが登録されているのを含意しません。 JET Guidelinesでは、登録バンドルは「IDNパッケージ」と呼ばれます。
* Reserved Label
* 予約されたラベル
A "reserved label" is a label in a registration bundle that is
not actually registered.
「予約されたラベル」は実際に示されない登録バンドルでのラベルです。
* Registry"
* 「登録」
A "registry" is the administrative authority for a DNS zone.
The registry is the body that enforces, and typically makes,
policies that are used in a particular zone in the DNS.
「登録」はDNSゾーンへの職務権限です。 登録はDNSの特定のゾーンで使用される方針を実施して、通常作るボディーです。
* Coded Character Set
* コード化文字集合
A "Coded Character Set" (CCS) is a list of characters and the
code positions assigned to them. ASCII and Unicode are CCSs.
「コード化文字集合」(CCS)は、キャラクタのリストと位置がそれらに割り当てたコードです。 ASCIIとユニコードはCCSsです。
* Language
* 言語
A "language" is something spoken by humans, independent of how
it is written or coded. ISO Standard 639 and IETF BCP 47 (RFC
3066) [RFC3066] list and define codes for identifying
languages.
「言語」はそれが書かれているか、またはどうコード化されるかの如何にかかわらず人間によって話された何かです。 ISO Standard639とIETF BCP47(RFC3066)[RFC3066]は、言語を特定するためにコードを記載して、定義します。
* Script
* スクリプト
A "script" is a collection of characters (glyphs, independent
of coding) that are used together, typically to represent one
or more languages. Note that the script for one language may
heavily overlap the script for another. This does not imply
that they have identical scripts.
「スクリプト」は通常、1つ以上の言語を表すのに一緒に使用されるキャラクタ(コード化の如何にかかわらずglyphs)の収集です。 1つの言語のためのスクリプトが別のもののために大いにスクリプトを重ね合わせるかもしれないことに注意してください。 これは、彼らには同じスクリプトがあるのを含意しません。
* Charset
* Charset
"Charset" is an IETF-invented term to describe, more or less,
the combination of a script, a CCS that encodes that script,
"Charset"は多少説明するIETFによって発明された用語です、スクリプトの組み合わせ、そのスクリプトをコード化するCCS
Klensin Informational [Page 8] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[8ページ]のRFC4290IDN登録は2005年12月に練習されます。
and rules for serializing encoded bytes that are stored on a
computer or transmitted over the network.
そして、連載のための規則はコンピュータで格納されるか、またはネットワークの上に伝えられるバイトをコード化しました。
The last four of these definitions are redundant with, but deliberately somewhat less precise than, the definitions in [RFC3536], which also provides sources. The two sets of definitions are intended to be consistent.
最後のこれらの4つの定義が余分ですが、故意にいくらか正確でない、[RFC3536](また、ソースを提供するもの)との定義 2セットの定義を一貫させていることを意図します。
1.3.3. Confusion, Fraud, and Cybersquatting
1.3.3. 混乱、詐欺、およびサイバースクワッティング
The term "confusion" is used very generically in this document to cover the entire range from accidental user misperception of the relationship between characters with some characteristic in common (typically appearance, sound, or meaning) to cybersquatting and (other) deliberately fraudulent attempts to exploit those relationships based on the nature of the characters.
「混乱」という用語は、キャラクタの間の関係の偶然のユーザ誤認からキャラクタの本質に基づくサイバースクワッティングとものを利用する(他)の故意に詐欺的な試みに共通(通常外観、音、または意味)の関係で独特のいくつかで全体の範囲を覆うのに非常に一般的に本書では使用されます。
1.4. A Review of the JET Guidelines
1.4. ジェットガイドラインのレビュー
1.4.1. JET Model
1.4.1. ジェットモデル
In the JET Guidelines model, a prospective registrant approaches the
registry for a zone (perhaps through an intermediate registrar) with
a candidate base registration -- a proposed name to be registered --
and a list of languages in which that name is to be interpreted. The
languages are defined according to the fairly high-resolution coding
of [RFC3066] or, if the registry considers it more appropriate, a
coding based on scripts such as those in [LTRU-Registry]. In this
way, Chinese as used on the mainland of the People's Republic of
China ("zh-cn") can, at registry option, consist of a somewhat
different list of characters (code points) and be represented by a
separate table compared to Chinese as used in Taiwan ("zh-tw").
JET Guidelinesモデルでは、見込み登録者は候補ベース登録(登録されるべき提案された名前)と解釈されるその名前がことである言語のリストでゾーン(恐らく中間的記録係を通した)に登録に近づきます。 公正に、[RFC3066]の高画質コード化か登録が、それが、より適切であると考えるときのコード化がそれらなどのスクリプトを基礎づけました。言語が定義される、[LTRU-登録]で。 台湾("zh-tw")で使用されるように別々のテーブルで中国語と比べて、このように、中華人民共和国の本土で使用される中国語は、登録選択でキャラクタ(コード・ポイント)のいくらか異なったリストから成って、表すことができます("zh-cn")。
The design of the JET Guidelines took one important constraint as a basis: IDNA was treated as a firm standard. A procedure that modified some portion of the IDNA functions, or was a variant on them, was considered a violation of those standards and should not be encouraged (or, probably, even permitted).
JET Guidelinesのデザインは基礎として1つの重要な規制をみなしました: IDNAは堅い規格として扱われました。 IDNA機能の何らかの部分を変更するか、またはそれらの上の異形であった手順を、それらの規格の違反であると考えて、奨励するべきではありません(または、たぶん受入れられさえします)。
Each registry is expected to construct (or obtain) a table for each language it considers relevant and appropriate. These tables list, for the particular zone, the characters permitted for that language. If a character does not appear as a base character (called a "valid code point" in the JET document) in that table, then a name containing it cannot be registered. If multiple languages are listed for the registration, then the character must appear in the tables for each of those languages.
各登録が組み立てると予想される、(入手、)、それが関連していて適切であると考える各言語のためのテーブル。 これらのテーブルはその言語のために受入れられたキャラクタを特定のゾーンに記載します。 キャラクタが基本文字(JETドキュメントに「有効なコード・ポイント」と呼ばれる)としてそのテーブルに現れないなら、それを含む名前は登録できません。 複数の言語が登録のために記載されるなら、キャラクタはテーブルにそれぞれのそれらの言語に関して現れなければなりません。
Klensin Informational [Page 9] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[9ページ]のRFC4290IDN登録は2005年12月に練習されます。
The tables may also contain columns that specify alternate or variant forms of the valid character. If these variants appear, they are used to synthesize labels that are alternatives to the original one. These labels are all reserved and can be registered or "activated" (placed into the DNS) only by the action or request of the original registrant; some (the "preferred variant labels") are typically registered automatically. The zone is expected to establish appropriate policies for situations in which the variant forms of one label conflict with already-reserved or already-registered labels.
また、テーブルは有効なキャラクタの補欠か異型を指定するコラムを含むかもしれません。 これらの異形が現れるなら、それらは、オリジナルのものへの代替手段であるラベルを統合するのに使用されます。 これらのラベルは、単に登録者本人の動作か要求ですべて予約されて、登録できるか、または「動かされる」(DNSに置かれます)。 或るもの(「都合のよい異形ラベル」)は自動的に通常登録されます。 ゾーンが異形が形成される既に予約されたか既に登録されたラベルとの1回のラベル闘争の状況のために適切な方針を確立すると予想されます。
Most of these concepts were introduced because of concerns about specific issues with CJK characters, beginning from the requirement that the use of Simplified Chinese by some registrants and Traditional Chinese by others not be permitted to create confusion or opportunities for fraud. While they may be applicable to registry tables constructed for alphabetic scripts, the translation should be done with care, since many analogies are not exact.
これらの概念の大部分はCJK文字の特定の問題に関する心配のために紹介されました、他のものによるいくつかの記入者とTraditional中国人によるSimplified中国人の使用が受入れられないという要件から詐欺の混乱か機会を作成し始めて。 それらがアルファベットスクリプトのために組み立てられた登録テーブルに適切であるかもしれない間、慎重に翻訳をするべきです、多くの類推が正確でないので。
Some of the important issues are discussed in the sections that follow, especially Section 3. The JET model may be considered as a variation on, and inspiration for, the model and method presented by the rest of this document, although the JET model has been completely developed only for CJK characters. Other languages or scripts, especially alphabetic ones, may require other variations.
従うセクションで切迫した課題のいくつかについて議論して、特にセクションは3です。 JETモデルが変化としてオンであると考えられるかもしれない、インスピレーション、JETモデルがCJK文字のためだけに完全に開発されましたが、このドキュメントの残りで提示されたモデルと方法。 他の言語かスクリプト(特にアルファベットのもの)が他の変化を必要とするかもしれません。
1.4.2. Reserved Names and Label Packages
1.4.2. 予約された名前とラベルパッケージ
A basic assumption of the JET model is that, if the evolution of specific characters or the properties of Unicode [Unicode] [Unicode32] or IDNA cause two strings to appear similar enough to cause confusion, then both should be registered by the same party or one of them should become unregisterable. The definition of "appear similar enough" will differ for different cultures and circumstance, and hence DNS zones, but the principle is fairly general. In the JET model, all of the variant strings are identified, some are registered into the DNS automatically, and others are simply reserved and can be registered, if at all, only by the original registrant. Other zones might find other policies appropriate. For example, a zone might conclude that having similar strings registered in the DNS was undesirable. If so, the list of variant strings would be used only to build a list of names that would be reserved and prohibited from being registered.
A basic assumption of the JET model is that, if the evolution of specific characters or the properties of Unicode [Unicode] [Unicode32] or IDNA cause two strings to appear similar enough to cause confusion, then both should be registered by the same party or one of them should become unregisterable. The definition of "appear similar enough" will differ for different cultures and circumstance, and hence DNS zones, but the principle is fairly general. In the JET model, all of the variant strings are identified, some are registered into the DNS automatically, and others are simply reserved and can be registered, if at all, only by the original registrant. Other zones might find other policies appropriate. For example, a zone might conclude that having similar strings registered in the DNS was undesirable. If so, the list of variant strings would be used only to build a list of names that would be reserved and prohibited from being registered.
Klensin Informational [Page 10] RFC 4290 IDN Registration Practices December 2005
Klensin Informational [Page 10] RFC 4290 IDN Registration Practices December 2005
1.5. Languages, Scripts, and Variants
1.5. Languages, Scripts, and Variants
1.5.1. Languages versus Scripts
1.5.1. Languages versus Scripts
Conversations about scripts -- collections of characters associated with particular languages -- are common when discussing character sets and codes. However, the boundaries between one script and another are not well-defined. The Unicode Standard ([Unicode], [Unicode32]), for example, does not define script boundaries at all, even though it is structured in terms of usually-related blocks of characters. The issue is complicated by the common origin of most alphabetic scripts in use in the world today (see, for example, [Drucker] or the more scholarly [Daniels]).
Conversations about scripts -- collections of characters associated with particular languages -- are common when discussing character sets and codes. However, the boundaries between one script and another are not well-defined. The Unicode Standard ([Unicode], [Unicode32]), for example, does not define script boundaries at all, even though it is structured in terms of usually-related blocks of characters. The issue is complicated by the common origin of most alphabetic scripts in use in the world today (see, for example, [Drucker] or the more scholarly [Daniels]).
Because of that history, certain characters (or, more precisely, symbols representing characters) appear in the scripts associated with multiple languages, sometimes with very different sounds or meanings. This differs from the CJK situation in which, if a character appears in more than one of the relevant languages, it will usually have the same interpretation in each one. For the subset of characters that actually are ideographs or pictographs, pronunciation is expected to vary widely while meaning is preserved. At least in part because of that similarity of meaning, it made sense in the JET case to permit a registration to specify multiple languages, to verify that the characters in the label string (the requested "Base registration") were valid for each, and then to generate variant labels using each language in turn. For many alphabetic languages, it may be more sensible to prohibit the label string submitted for registration from being associated with more than one language. Indeed, "one label, one language" has been suggested as an important barrier against common sources of "look-alike" confusion. For example, the imposition of that rule in a zone would prevent the insertion of a few Greek or Cyrillic characters with shapes identical to the Latin ones into what was otherwise a Latin-based string. For a particular table, the list of base characters may be thought of as the script associated with the relevant language, with the understanding that the table design does not prevent the same character from appearing in the tables for multiple languages.
Because of that history, certain characters (or, more precisely, symbols representing characters) appear in the scripts associated with multiple languages, sometimes with very different sounds or meanings. This differs from the CJK situation in which, if a character appears in more than one of the relevant languages, it will usually have the same interpretation in each one. For the subset of characters that actually are ideographs or pictographs, pronunciation is expected to vary widely while meaning is preserved. At least in part because of that similarity of meaning, it made sense in the JET case to permit a registration to specify multiple languages, to verify that the characters in the label string (the requested "Base registration") were valid for each, and then to generate variant labels using each language in turn. For many alphabetic languages, it may be more sensible to prohibit the label string submitted for registration from being associated with more than one language. Indeed, "one label, one language" has been suggested as an important barrier against common sources of "look-alike" confusion. For example, the imposition of that rule in a zone would prevent the insertion of a few Greek or Cyrillic characters with shapes identical to the Latin ones into what was otherwise a Latin-based string. For a particular table, the list of base characters may be thought of as the script associated with the relevant language, with the understanding that the table design does not prevent the same character from appearing in the tables for multiple languages.
Indeed, this notion of a script that is local and specifically identified can be turned around: so-called "language tables" are associated with languages only insofar as thinking about the character structure and word forms associated with a given language helps to inform the construction of the table. A country like Finland, for example, might select among:
Indeed, this notion of a script that is local and specifically identified can be turned around: so-called "language tables" are associated with languages only insofar as thinking about the character structure and word forms associated with a given language helps to inform the construction of the table. A country like Finland, for example, might select among:
o One table each for Finnish, Swedish, and English characters and
conventions, permitting a string to be registered in one, two, or
o One table each for Finnish, Swedish, and English characters and conventions, permitting a string to be registered in one, two, or
Klensin Informational [Page 11] RFC 4290 IDN Registration Practices December 2005
Klensin Informational [Page 11] RFC 4290 IDN Registration Practices December 2005
all three languages. However, a three-language registration would
necessarily prohibit any characters that did not appear in all
three languages, since the label would make little sense
otherwise.
all three languages. However, a three-language registration would necessarily prohibit any characters that did not appear in all three languages, since the label would make little sense otherwise.
o One table each, but with a "one label, one language" rule for the
zone.
o One table each, but with a "one label, one language" rule for the zone.
o A combined table based on the observation that all three writing
systems were based on Roman characters and that the possibilities
for confusion of interest to the registry would not be reduced by
"language" differentiation. This option raises an interesting
issue about language labeling as described in Section 1.4.1; see
the discussion in Section 7 below.
o A combined table based on the observation that all three writing systems were based on Roman characters and that the possibilities for confusion of interest to the registry would not be reduced by "language" differentiation. This option raises an interesting issue about language labeling as described in Section 1.4.1; see the discussion in Section 7 below.
Regardless of what decisions were made about those languages and scripts, they might have a separate table for registration of labels containing Cyrillic characters. That table might contain some Roman-derived characters (either as base characters or as variants), just as some CJK tables do. See also Section 2, below.
Regardless of what decisions were made about those languages and scripts, they might have a separate table for registration of labels containing Cyrillic characters. That table might contain some Roman-derived characters (either as base characters or as variants), just as some CJK tables do. See also Section 2, below.
Tables that present multiple languages, as described above, have introduced confusion and discomfort among those who have failed to understand these definitions. The consequence of these definitions is that use of a language or script code in a registration is a mnemonic, rather than a normative statement about the language or script itself. When that confusion is likely to occur, it is appropriate to simply use the registry identifier and a sequence number to identify the registration.
Tables that present multiple languages, as described above, have introduced confusion and discomfort among those who have failed to understand these definitions. The consequence of these definitions is that use of a language or script code in a registration is a mnemonic, rather than a normative statement about the language or script itself. When that confusion is likely to occur, it is appropriate to simply use the registry identifier and a sequence number to identify the registration.
As the JET Guidelines stress, no tables or systems of this type -- even if identified with a language as a means of defining or describing the table -- can assure linguistic or even syntactic correctness of labels with regard to that language. That assurance may not be possible without human intervention or at least dictionary lookups of complete proposed labels. It may even not be desirable to attempt that level of correctness (see Section 2).
As the JET Guidelines stress, no tables or systems of this type -- even if identified with a language as a means of defining or describing the table -- can assure linguistic or even syntactic correctness of labels with regard to that language. That assurance may not be possible without human intervention or at least dictionary lookups of complete proposed labels. It may even not be desirable to attempt that level of correctness (see Section 2).
Of course, if any language-based tests or constraints, including "one label, one language", are to be applied to limit the associated sources of confusion, each zone must have a table for each language in which it expects to accept registrations. The notion of a single combined table for the zone is, in the general case, simply unworkable. One could use a single table for the zone if the intent were to impose only minimal restrictions, e.g., to force alphabetic and numeric characters only, excluding symbols and punctuation. That type of restriction might be useful in eliminating some problems, such as those of unreadable labels, but it would be unlikely to be
Of course, if any language-based tests or constraints, including "one label, one language", are to be applied to limit the associated sources of confusion, each zone must have a table for each language in which it expects to accept registrations. The notion of a single combined table for the zone is, in the general case, simply unworkable. One could use a single table for the zone if the intent were to impose only minimal restrictions, e.g., to force alphabetic and numeric characters only, excluding symbols and punctuation. That type of restriction might be useful in eliminating some problems, such as those of unreadable labels, but it would be unlikely to be
Klensin Informational [Page 12] RFC 4290 IDN Registration Practices December 2005
Klensin Informational [Page 12] RFC 4290 IDN Registration Practices December 2005
very helpful with, e.g., confusion caused by similar-looking characters.
very helpful with, e.g., confusion caused by similar-looking characters.
1.5.2. Variant Selection
1.5.2. Variant Selection
The area of character variants is rife with difficulties (and perhaps opportunities). There is no universal agreement about which base characters have variants, or if they do, what those variants are. For example, in some regions of the world and in some languages, LATIN SMALL LETTER O WITH DIAERESIS (U+00F6) and LATIN SMALL LETTER O WITH STROKE (U+00F8) are variants of each other, while in other regions, most people would think that LATIN SMALL LETTER O WITH STROKE has no variants. In some cases, the list of variants is difficult to enumerate. For example, it required several years for the Chinese language community to create variant tables for use with IDNA, and it remains, at the time of this writing, questionable how widely those tables will be accepted among users of Chinese from areas of the world other than those represented by the groups that created them.
The area of character variants is rife with difficulties (and perhaps opportunities). There is no universal agreement about which base characters have variants, or if they do, what those variants are. For example, in some regions of the world and in some languages, LATIN SMALL LETTER O WITH DIAERESIS (U+00F6) and LATIN SMALL LETTER O WITH STROKE (U+00F8) are variants of each other, while in other regions, most people would think that LATIN SMALL LETTER O WITH STROKE has no variants. In some cases, the list of variants is difficult to enumerate. For example, it required several years for the Chinese language community to create variant tables for use with IDNA, and it remains, at the time of this writing, questionable how widely those tables will be accepted among users of Chinese from areas of the world other than those represented by the groups that created them.
Thus, the first thing a registry should ask is whether or not any of the characters that they want to permit to be used have variants. If not, the registry's work is much simpler. This is not to say that a registry should ignore variants if they exist: adding variants after a registry has started to take registrations will be nearly as difficult administratively as removing characters from the list of acceptable characters. That is, if a registry later decides that two characters are variants of each other, and there are actively-used names in the zones that differ only on the new variants, the registry might have to transfer ownership of one of the names to a different owner, using some process that is certain to be controversial.
Thus, the first thing a registry should ask is whether or not any of the characters that they want to permit to be used have variants. If not, the registry's work is much simpler. This is not to say that a registry should ignore variants if they exist: adding variants after a registry has started to take registrations will be nearly as difficult administratively as removing characters from the list of acceptable characters. That is, if a registry later decides that two characters are variants of each other, and there are actively-used names in the zones that differ only on the new variants, the registry might have to transfer ownership of one of the names to a different owner, using some process that is certain to be controversial.
This situation in likely to be much easier for areas and zones that use characters that previously did not occur in the DNS at all than it will be for zones in which non-English labels have been registered in ASCII characters for some time, presumably because the language of interest uses additional "Latin" characters with some conventions when only ASCII is available. In the former case, the rules and conventions can be established before any registrations occur. In the latter, there may be conflicts or opportunities for confusion between existing registrations and now-permitted Roman-based characters that do not appear in ASCII. For example, a domain name might exist today that uses the name of a city in Canada spelled as "Montreal". If the zone in which it occurs changes its rules to permit the use of the character LATIN SMALL LETTER E WITH ACUTE (U+00E9), does the name of the city, spelled (correctly) using that character, conflict with the existing domain name registration?
This situation in likely to be much easier for areas and zones that use characters that previously did not occur in the DNS at all than it will be for zones in which non-English labels have been registered in ASCII characters for some time, presumably because the language of interest uses additional "Latin" characters with some conventions when only ASCII is available. In the former case, the rules and conventions can be established before any registrations occur. In the latter, there may be conflicts or opportunities for confusion between existing registrations and now-permitted Roman-based characters that do not appear in ASCII. For example, a domain name might exist today that uses the name of a city in Canada spelled as "Montreal". If the zone in which it occurs changes its rules to permit the use of the character LATIN SMALL LETTER E WITH ACUTE (U+00E9), does the name of the city, spelled (correctly) using that character, conflict with the existing domain name registration?
Klensin Informational [Page 13] RFC 4290 IDN Registration Practices December 2005
Klensin Informational [Page 13] RFC 4290 IDN Registration Practices December 2005
Certainly, if both are permitted, and permitted to be registered by separate parties, there are many opportunities for confusion.
Certainly, if both are permitted, and permitted to be registered by separate parties, there are many opportunities for confusion.
Of course, zone managers should inform all current registrants when the registration policy for the zone changes. This includes the times when IDN characters are first allowed in the zone, when additional characters are permitted, and when any change occurs in the character variant tables.
Of course, zone managers should inform all current registrants when the registration policy for the zone changes. This includes the times when IDN characters are first allowed in the zone, when additional characters are permitted, and when any change occurs in the character variant tables.
Many languages contain two variants for a character, one of which is strongly preferred. A registry might restrict the base registration to the preferred form, or it might allow any form for the base registration. If the variant tables are created carefully, the resulting bundles will be the same, but some registries will give special status to the base registration such as its appearance in "Whois" databases.
Many languages contain two variants for a character, one of which is strongly preferred. A registry might restrict the base registration to the preferred form, or it might allow any form for the base registration. If the variant tables are created carefully, the resulting bundles will be the same, but some registries will give special status to the base registration such as its appearance in "Whois" databases.
1.6. Variants are not a Universal Remedy
1.6. Variants are not a Universal Remedy
It is worth stressing that there are many obvious opportunities for confusion that variant systems, by virtue of being based on processing of individual characters, cannot address. For example, if a language can be written with more than one script, or transliterations of the language into another script are common, variant models are insufficient to prevent conflicting registration of the related forms. Avoiding those types of problems would require different mechanisms, perhaps based on phonetic or natural language processing techniques for the entire proposed base registration.
It is worth stressing that there are many obvious opportunities for confusion that variant systems, by virtue of being based on processing of individual characters, cannot address. For example, if a language can be written with more than one script, or transliterations of the language into another script are common, variant models are insufficient to prevent conflicting registration of the related forms. Avoiding those types of problems would require different mechanisms, perhaps based on phonetic or natural language processing techniques for the entire proposed base registration.
1.7. Reservations and Exclusions
1.7. Reservations and Exclusions
1.7.1. Sequence Exclusions for Valid Characters
1.7.1. Sequence Exclusions for Valid Characters
The JET Guidelines are based on processing only single characters. Pairs or longer sequences of characters can, at the option of the registry, be handled through what the Guidelines describe as "additional processing". These registry-specific string processing procedures are specifically permitted by the guidelines to supplement the per-character processing that generates the variants.
The JET Guidelines are based on processing only single characters. Pairs or longer sequences of characters can, at the option of the registry, be handled through what the Guidelines describe as "additional processing". These registry-specific string processing procedures are specifically permitted by the guidelines to supplement the per-character processing that generates the variants.
A different zone with different needs could use a modified version of the table structure, or different types of additional processing, to prohibit particular sequences of characters by marking them as invalid, and to accept characters by marking them as valid. Other modifications or extensions might be designed to prevent certain letters from appearing at the beginning or end of labels. The use of regular expressions in the "valid characters" column might be one way
A different zone with different needs could use a modified version of the table structure, or different types of additional processing, to prohibit particular sequences of characters by marking them as invalid, and to accept characters by marking them as valid. Other modifications or extensions might be designed to prevent certain letters from appearing at the beginning or end of labels. The use of regular expressions in the "valid characters" column might be one way
Klensin Informational [Page 14] RFC 4290 IDN Registration Practices December 2005
Klensin Informational [Page 14] RFC 4290 IDN Registration Practices December 2005
to implement these types of restrictions, but there has been no experience so far with that approach.
to implement these types of restrictions, but there has been no experience so far with that approach.
In particular, in some scripts derived from Roman characters, sequences that have historically been typographically represented by single "ligature" or "digraph" characters may also be represented by the separate characters (e.g., "ae" for U+00E6 or "ij" for U+0133). If it is desired to either prohibit these, or to treat them as variants, some extensions to the single-character JET model may be needed. Some careful thinking about IDNA (especially nameprep) may also be needed, since some of these combinations are excluded there).
In particular, in some scripts derived from Roman characters, sequences that have historically been typographically represented by single "ligature" or "digraph" characters may also be represented by the separate characters (e.g., "ae" for U+00E6 or "ij" for U+0133). If it is desired to either prohibit these, or to treat them as variants, some extensions to the single-character JET model may be needed. Some careful thinking about IDNA (especially nameprep) may also be needed, since some of these combinations are excluded there).
1.7.2. Character Pairing Issues
1.7.2. Character Pairing Issues
Some character pairings -- the use of a character form (glyph) in one language and a different form with the same properties in a related one -- closely approximate the issues with mapping between Traditional and Simplified Chinese, although the history is different. For example, it might be useful to have "o" with a stroke (U+00F8) as a variant for "o" with diaeresis above it (U+00F6) (and the equivalent upper-case pair) in a Swedish table, and vice versa in a Norwegian one, or to prohibit one of these characters entirely in each table. In a German table, U+00F8 would presumably be prohibited, while U+00F6 might have "oe" as a variant. Obviously, if the relevant language of registration is unknown, this type of variant matching cannot be applied in any sensible way.
Some character pairings -- the use of a character form (glyph) in one language and a different form with the same properties in a related one -- closely approximate the issues with mapping between Traditional and Simplified Chinese, although the history is different. For example, it might be useful to have "o" with a stroke (U+00F8) as a variant for "o" with diaeresis above it (U+00F6) (and the equivalent upper-case pair) in a Swedish table, and vice versa in a Norwegian one, or to prohibit one of these characters entirely in each table. In a German table, U+00F8 would presumably be prohibited, while U+00F6 might have "oe" as a variant. Obviously, if the relevant language of registration is unknown, this type of variant matching cannot be applied in any sensible way.
1.8. The Registration Bundle
1.8. The Registration Bundle
1.8.1. Definitions and Structure
1.8.1. Definitions and Structure
As one of its critical innovations, the JET model defines an "IDN
package", known in this document as a "registration bundle", which
consists of the primary registered string (which is used as the name
of the bundle), the information about the language table(s) used, the
variant labels for that string, and indications of which of those
labels are registered in the relevant zone file ("activated" in the
JET terminology). Registration bundles are also atomic -- one can
not add or remove variant labels from one without unregistering the
entire package. A label exists in only one registration bundle at a
time; if a new label is registered that would generate a variant that
matches one that appears in an existing package, that variant simply
is not included in the second package. A subsequent de-registration
of the first package does not cause the variant to be added to the
second. While it might be possible to change this in other models,
the JET conclusion was that other options would be far too complex to
implement and operate and would cause many new types of name
conflicts.
As one of its critical innovations, the JET model defines an "IDN package", known in this document as a "registration bundle", which consists of the primary registered string (which is used as the name of the bundle), the information about the language table(s) used, the variant labels for that string, and indications of which of those labels are registered in the relevant zone file ("activated" in the JET terminology). Registration bundles are also atomic -- one can not add or remove variant labels from one without unregistering the entire package. A label exists in only one registration bundle at a time; if a new label is registered that would generate a variant that matches one that appears in an existing package, that variant simply is not included in the second package. A subsequent de-registration of the first package does not cause the variant to be added to the second. While it might be possible to change this in other models, the JET conclusion was that other options would be far too complex to implement and operate and would cause many new types of name conflicts.
Klensin Informational [Page 15] RFC 4290 IDN Registration Practices December 2005
Klensin Informational [Page 15] RFC 4290 IDN Registration Practices December 2005
1.8.2. Application of the Registration Bundle
1.8.2. Application of the Registration Bundle
A registry has three options for handling the case where the registration bundle contains more than one label. The policy options are:
A registry has three options for handling the case where the registration bundle contains more than one label. The policy options are:
o Register and resolve all labels in the zone, making the zone
information identical to that of the registered labels. This
option will allow end users to find names with variants more
easily, but will result in larger zone files. For some language
tables, the zone file could become so large that it could
negatively affect the ability of the registry to perform name
resolution. If the base registration contains several characters
that have equivalents, the owner could end up having to take care
of large numbers of zones. For instance, if DIGIT ONE is a
variant of LATIN SMALL LETTER L, the owner of the domain name all-
lollypops.example.com will have to manage 32 zones. If the intent
is to keep the contents of those zones identical, the owner may
then face a significant administrative problem. If other concerns
dictate short times to live and absolute consistency of DNS
responses, the challenges may be nearly impossible.
o Register and resolve all labels in the zone, making the zone information identical to that of the registered labels. This option will allow end users to find names with variants more easily, but will result in larger zone files. For some language tables, the zone file could become so large that it could negatively affect the ability of the registry to perform name resolution. If the base registration contains several characters that have equivalents, the owner could end up having to take care of large numbers of zones. For instance, if DIGIT ONE is a variant of LATIN SMALL LETTER L, the owner of the domain name all- lollypops.example.com will have to manage 32 zones. If the intent is to keep the contents of those zones identical, the owner may then face a significant administrative problem. If other concerns dictate short times to live and absolute consistency of DNS responses, the challenges may be nearly impossible.
o Block all labels other than the registered label so they cannot be
registered in the future. This option does not increase the size
of the zone file and provides maximum safety against false
positives, but it may cause end users to not be able to find names
with variants that they would expect. If the base registration
contains characters that have equivalents, Internet users who do
not know what base characters were used in the registration will
not know what character to type in to get a DNS response. For
instance, if DIGIT ONE is a variant of LATIN SMALL LETTER L, and
LATIN SMALL LETTER L is a variant of DIGIT ONE, the user who sees
"pale.example.com" will not know whether to type a "1" or a "l"
after the "pa" in the first label.
o Block all labels other than the registered label so they cannot be registered in the future. This option does not increase the size of the zone file and provides maximum safety against false positives, but it may cause end users to not be able to find names with variants that they would expect. If the base registration contains characters that have equivalents, Internet users who do not know what base characters were used in the registration will not know what character to type in to get a DNS response. For instance, if DIGIT ONE is a variant of LATIN SMALL LETTER L, and LATIN SMALL LETTER L is a variant of DIGIT ONE, the user who sees "pale.example.com" will not know whether to type a "1" or a "l" after the "pa" in the first label.
o Resolve some labels and block some other labels. This option is
likely to cause the most confusion with users because including
some variants will cause a name to be found, but using other
variants will cause the name to be not found. For example, even
if people understood that DIGIT ONE and LATIN SMALL LETTER L were
variants, a typical DNS user wouldn't know which character to type
because they wouldn't know whether this pair were used to register
or block the labels. However, this option can be used to balance
the desires of the name owner (that every possible attempt to
enter their name will work) with the desires of the zone
administrator (to make the zone more manageable and possibly to be
compensated for greater amounts of work needed for a single
o Resolve some labels and block some other labels. This option is likely to cause the most confusion with users because including some variants will cause a name to be found, but using other variants will cause the name to be not found. For example, even if people understood that DIGIT ONE and LATIN SMALL LETTER L were variants, a typical DNS user wouldn't know which character to type because they wouldn't know whether this pair were used to register or block the labels. However, this option can be used to balance the desires of the name owner (that every possible attempt to enter their name will work) with the desires of the zone administrator (to make the zone more manageable and possibly to be compensated for greater amounts of work needed for a single
Klensin Informational [Page 16] RFC 4290 IDN Registration Practices December 2005
Klensin Informational [Page 16] RFC 4290 IDN Registration Practices December 2005
registration). For many circumstances, it may be the most
attractive option.
registration). For many circumstances, it may be the most attractive option.
In all cases, at least the registered label should appear in the zone. It would be almost impossible to describe to name owners why the name that they asked for is not in the zone, but some other name that they now control is. By implication, if the requested label is already registered, the entire registration request must be rejected.
In all cases, at least the registered label should appear in the zone. It would be almost impossible to describe to name owners why the name that they asked for is not in the zone, but some other name that they now control is. By implication, if the requested label is already registered, the entire registration request must be rejected.
2. Some Implications of This Approach
2. Some Implications of This Approach
Historically, DNS labels were considered to be arbitrary identifier strings, without any inherent meaning. Even in ASCII, there was no requirement that labels form words. Labels that could not possibly represent words in any Romance or Germanic language (the languages that have been written in "Latin" scripts since medieval times or earlier) have actually been quite common. In general, in those languages, words contain at least one vowel and do not have embedded numbers. As a result, a string such as "bc345df" cannot possibly be a "word" in these languages. More generally, the more one moves toward "language"-based registry restrictions, the less it is going to be possible to construct labels out of fanciful strings. While fanciful strings are terrible candidates for "words", they may make very good identifiers. To take a trivial example using only ASCII characters, "rtr32w", "rtr32x", and "rtr32z" might be very good DNS labels for a particular zone and application. However, given the embedded digits and lack of vowels, they, like the "bc345df" example given above, would fail even the most superficial of tests for valid English (or German or French (etc.)) word forms.
Historically, DNS labels were considered to be arbitrary identifier strings, without any inherent meaning. Even in ASCII, there was no requirement that labels form words. Labels that could not possibly represent words in any Romance or Germanic language (the languages that have been written in "Latin" scripts since medieval times or earlier) have actually been quite common. In general, in those languages, words contain at least one vowel and do not have embedded numbers. As a result, a string such as "bc345df" cannot possibly be a "word" in these languages. More generally, the more one moves toward "language"-based registry restrictions, the less it is going to be possible to construct labels out of fanciful strings. While fanciful strings are terrible candidates for "words", they may make very good identifiers. To take a trivial example using only ASCII characters, "rtr32w", "rtr32x", and "rtr32z" might be very good DNS labels for a particular zone and application. However, given the embedded digits and lack of vowels, they, like the "bc345df" example given above, would fail even the most superficial of tests for valid English (or German or French (etc.)) word forms.
It is worth noting that several DNS experts have suggested that a number of problems could be solved by prohibiting meaningful names in labels, requiring instead that the labels be random or nonsense strings. If methods similar to those discussed in this document were used to force identifiers to be closer to meaningful words in real languages, the result would be directly contradictory to those "random name" approaches.
It is worth noting that several DNS experts have suggested that a number of problems could be solved by prohibiting meaningful names in labels, requiring instead that the labels be random or nonsense strings. If methods similar to those discussed in this document were used to force identifiers to be closer to meaningful words in real languages, the result would be directly contradictory to those "random name" approaches.
Interestingly, if one were trying to develop an "only words" system, a rather different -- but very restrictive -- model could be developed using lookups in a dictionary for the relevant language and a listing of valid business names for the relevant area. If a string did not appear in either, it would not be permitted to be registered. Models that require a prior national business listing (or registration) that is identical to the proposed domain name label have historically been used to restrict registrations in some country-code top level domains, so this is not a new idea. On the other hand, if look-alike characters are a concern, even that type of
Interestingly, if one were trying to develop an "only words" system, a rather different -- but very restrictive -- model could be developed using lookups in a dictionary for the relevant language and a listing of valid business names for the relevant area. If a string did not appear in either, it would not be permitted to be registered. Models that require a prior national business listing (or registration) that is identical to the proposed domain name label have historically been used to restrict registrations in some country-code top level domains, so this is not a new idea. On the other hand, if look-alike characters are a concern, even that type of
Klensin Informational [Page 17] RFC 4290 IDN Registration Practices December 2005
Klensin Informational [Page 17] RFC 4290 IDN Registration Practices December 2005
rule (or restriction) would still not avoid the need to consider character variants.
rule (or restriction) would still not avoid the need to consider character variants.
Consequently, registries applying the principles outlined in this document should be careful not to apply more severe restrictions than are reasonable and appropriate while, at the same time, being aware of how difficult it usually is to add restrictions at a later time.
Consequently, registries applying the principles outlined in this document should be careful not to apply more severe restrictions than are reasonable and appropriate while, at the same time, being aware of how difficult it usually is to add restrictions at a later time.
3. Possible Modifications of the JET Model
3. Possible Modifications of the JET Model
The JET model was designed for CJK characters. The discussion above implies that some extensions to it may be needed to handle the characteristics of various alphabetic scripts and the decisions that might be made about them in different zones. Those extensions might include facilities to process:
The JET model was designed for CJK characters. The discussion above implies that some extensions to it may be needed to handle the characteristics of various alphabetic scripts and the decisions that might be made about them in different zones. Those extensions might include facilities to process:
o Two-character (or more) sequences, such as ligatures and
typographic spelling conventions, as variants.
o Two-character (or more) sequences, such as ligatures and typographic spelling conventions, as variants.
o Regular expressions or some other mechanism for dealing with
string positions of characters (e.g., characters that must, or
must not, appear at the beginning or end of strings).
o Regular expressions or some other mechanism for dealing with string positions of characters (e.g., characters that must, or must not, appear at the beginning or end of strings).
o Delimiter breaks to permit multiple languages to be used,
separately, within the same label. E.g., is it possible to define
a label as consisting of two or more components, each in a
different language, with some particular delimiter to define the
boundaries of the components?
o Delimiter breaks to permit multiple languages to be used, separately, within the same label. E.g., is it possible to define a label as consisting of two or more components, each in a different language, with some particular delimiter to define the boundaries of the components?
4. Conclusions and Recommendations About the General Approach
4. Conclusions and Recommendations About the General Approach
After examining the implications of the potential use of the full range of characters permitted by IDNA in DNS labels, multiple groups, including IESG [IESG-IDN] and ICANN [ICANN-IDN] [ICANN-IDN2], have concluded that some restrictions are needed to prevent many forms of user confusion about the actual structure of a name or the word, phrase, or term that it appears to spell out. The best way to approach such restrictions appears to draw from the language and culture of the community of registrants and users in the relevant zone: if particular characters are likely to be surprising or unintelligible to both of those groups, it is probably wise to not permit them to be used in registrations. Registration restrictions can be carried much further than restricting permitted characters to a selected Unicode subset. The idea of a reserved "bundle" of related labels permits probably-confusing combinations or sets of characters to be bound together, under the control of a single registrant. While that registrant might still use the package in a way that confused his or her own users (the approach outlined here
After examining the implications of the potential use of the full range of characters permitted by IDNA in DNS labels, multiple groups, including IESG [IESG-IDN] and ICANN [ICANN-IDN] [ICANN-IDN2], have concluded that some restrictions are needed to prevent many forms of user confusion about the actual structure of a name or the word, phrase, or term that it appears to spell out. The best way to approach such restrictions appears to draw from the language and culture of the community of registrants and users in the relevant zone: if particular characters are likely to be surprising or unintelligible to both of those groups, it is probably wise to not permit them to be used in registrations. Registration restrictions can be carried much further than restricting permitted characters to a selected Unicode subset. The idea of a reserved "bundle" of related labels permits probably-confusing combinations or sets of characters to be bound together, under the control of a single registrant. While that registrant might still use the package in a way that confused his or her own users (the approach outlined here
Klensin Informational [Page 18] RFC 4290 IDN Registration Practices December 2005
Klensin Informational [Page 18] RFC 4290 IDN Registration Practices December 2005
will not prevent either ill-though-out ideas or stupidity), the possibility of turning potential confusion into a hostile attack would be considerably reduced.
どちらも防がない、病気、出ている、考えか無知)、潜在的混乱を敵対的な攻撃に変える可能性はかなり減少するでしょう。
At the same time, excessive restrictions may make DNS identifiers less useful for their original purpose: identifying particular hosts and similar resources on the network in an orderly way. Registries creating rules and policies about what can be registered in particular zones -- whether those are based on the JET Guidelines or the suggestions in this document -- should balance the need for restrictions against the need for flexibility in constructing identifiers.
同時に、過度の制限はDNSをそれほど彼らの初心の役に立たない識別子にするかもしれません: 規則的な方法でネットワークに関する特定のホストと同様のリソースを特定します。 柔軟性の必要性に対してそれらが本書ではJET Guidelinesか提案に基づいているか否かに関係なく、特定のゾーンに何を登録できるかに関する規則と方針を作成する登録は識別子を構成する際に制限の必要性のバランスをとるべきです。
The discussion above provides many options that could be selected, defined, and applied in different ways in different registries (zones). Registrars and registrants would almost certainly prefer systems in which they can predict, at least to a first order approximation, the implications of a particular potential registration. Predictability of that sort probably requires more standards, and less flexibility, than the model itself might suggest.
上の議論は異なった登録(ゾーン)で異なった方法で選択して、定義されて、適用できた多くのオプションを提供します。 記録係と記入者はほぼ確実に、彼らが少なくとも最初のオーダー近似に特定の潜在的登録の含意を予測できるシステムを好むでしょう。 その種類の予見性はたぶんモデル自体が勧めるかもしれないよりさらに多くの規格、および、より少ない柔軟性を必要とします。
5. A Model Table Format
5. モデルテーブル形式
The format of the table is meant to be machine-readable but not human-readable. It is fairly trivial to convert the table into one that can be read by people.
機械可読ですが、テーブルの形式が人間読み込み可能でないことが意味されます。 人々が読むことができるものにテーブルを変換するのはかなり些細です。
Each character in the table is given in the "U+" notation for Unicode characters. The lines of the table are terminated with either a carriage return character (ASCII 0x0D), a linefeed character (ASCII 0x0A), or a sequence of carriage return followed by linefeed (ASCII 0x0D 0x0A). The order of the lines in the table may or may not matter, depending on how the table is constructed.
ユニコード文字のために「U+」記法でテーブルの各キャラクタを与えます。 テーブルの線は復帰文字(ASCII0x0D)、ラインフィードキャラクタ(ASCII0x0A)かラインフィードがあとに続いた復帰の系列(ASCII0x0D 0x0A)のどちらかで終えられます。 テーブルがどう組み立てられるかによって、テーブルでの線の注文は重要であるかもしれません。
Comment lines in the table are preceded with a "#" character (ASCII 0x2C).
テーブルの注釈行は「#」キャラクタ(ASCII0x2C)と共に先行されています。
Each non-comment line in the table starts with the character that is
allowed in the registry and expected to be used in registrations,
which is also called the "base character". If the base character has
any variants, the base character is followed by a vertical bar
character ("|", ASCII 0x7C) and the variant string. If the base
character has more than one variant, the variants are separated by a
colon (":", ASCII 0x3A). Strings are given with a hyphen ("-", ASCII
0x2D) between each character. Comments beginning with a "#" (ASCII
0x2C), and may be preceded by spaces (" ", ASCII 0x20).
登録に許容されていて、登録証明書に使用されると予想されるキャラクタとのテーブル始めにおけるそれぞれの非注釈行。(また、その注釈行は「基本文字」と呼ばれます)。 基本文字が何か異形を持っているなら、基本文字が縦棒キャラクタによってついて来られている、(「|」、ASCII0x7C) そして、異形ストリング。 基本文字が1つ以上の異形を持っているなら、異形がコロンによって切り離される、(「:」、ASCII0x3A)。 各キャラクタの間には、ハイフン(「-」、ASCII0x2D)がある状態で、ストリングを与えます。 コメントを「#」(ASCII0x2C)で始まって、空間が先行するかもしれない、(「「ASCII0x20)、」
Klensin Informational [Page 19] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[19ページ]のRFC4290IDN登録は2005年12月に練習されます。
The following is an example of how a table might look. The entries in this table are purposely silly and should not be used by any registry as the basis for choosing variants. For the example, assume that the registry:
↓これはテーブルがどう見えるかもしれないかに関する例です。 このテーブルのエントリーをわざわざ愚かであり、どんな登録も異形を選ぶ基礎として使用するべきではありません。 例に関しては、それが登録であると仮定してください:
o allows the FOR ALL character (U+2200) with no variants
o 異形なしでFOR ALLキャラクタ(U+2200)を許容します。
o allows the COMPLEMENT character (U+2201) which has a single
variant of LATIN CAPITAL LETTER C (U+0043)
o LATIN CAPITAL LETTER Cの単一の異形を持っているCOMPLEMENTキャラクタ(U+2201)を許容します。(U+0043)
o allows the PROPORTION character (U+2237) which has one variant
which is the string COLON (U+003A) COLON (U+003A)
o ストリングである1つの異形を持っているPROPORTIONキャラクタ(U+2237)にコロン(U+003A)コロンを許容します。(U+003A)
o allows the PARTIAL DIFFERENTIAL character (U+2202) which has two
variants: LATIN SMALL LETTER D (U+0064) and GREEK SMALL LETTER
DELTA (U+03B4)
o 2つの異形を持っているPARTIAL DIFFERENTIALキャラクタ(U+2202)は許容します: ラテン語の小文字D(U+0064)とギリシアの小文字デルタ(U+03B4)
The table contents (after any required header information, see [IANA-language-registry] and the discussion in Section 7 below) would look like:
テーブルコンテンツ(いずれもヘッダー情報を必要とした後に以下のセクション7で[IANA言語登録]と議論を見る)に似ているでしょう:
# An example of a table
U+2200
U+2201|U+0043
U+2237|U+003A-U+003A # Note that the variant is a string
U+2202|U+0064:U+03B4 # Two variants for the same character
# テーブルU+2200U +2201に関する例|U+0043U+2237|異形がそうであるU+003A-U+003A#Note、aはU+2202を結びます。|U+0064: 同じキャラクタのためのU+03B4#2つの異形
Implementers of table processors should remember that there are tens
of thousands of characters whose codepoints are greater than 0xFFFF.
Thus, any program that assumes that each character in the table is
represented in exactly six octets ("U", "+", and four octets
representing the character value) will fail with tables that use
characters whose value is greater than 0xFFFF.
テーブルプロセッサのImplementersは、codepointsが0xFFFFよりすばらしい何万ものキャラクタがあったのを覚えているはずです。 したがって、テーブルの各キャラクタがまさに6つの八重奏(「U」、「+」、および文字値を表す4つの八重奏)で代理をされると仮定するどんなプログラムも値が0xFFFFより大きいキャラクタを使用するテーブルで失敗するでしょう。
6. A Model Label Registration Procedure: "CreateBundle"
6. モデルラベル登録手順: "CreateBundle"
This procedure has three inputs:
この手順に、3つの入力があります:
1. the proposed base registration,
1. 提案されたベース登録
2. the language (or script, if the registration is script-based, but
"language" is used for convenience below) for the proposed base
registration, and
そして2. 提案されたベース登録のための言語(以下の便宜のために登録がスクリプトベースであるなら使用される「言語」だけ、に原稿を書く)。
3. the processing table associated with that language.
3. 処理テーブルはその言語と交際しました。
The output of the process is either failure (the base registration cannot be registered at all), or a registration bundle that contains
過程の出力は、それが含む失敗(ベース登録を全く登録できない)か登録バンドルのどちらかです。
Klensin Informational [Page 20] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[20ページ]のRFC4290IDN登録は2005年12月に練習されます。
one or more labels (always including the base registration). As described earlier, the registration bundle should be stored with its date of creation so that issues with overlapping elements between bundles can later be resolved on a first-come, first-served basis.
1個以上のラベル(いつもベース登録を含んでいます)。 より早く説明されるように、登録バンドルは後で先着順の方式でバンドルの間の要素を重ね合わせる問題を解決できるように創造の日付で格納されるべきです。
There are two steps to processing the registration:
登録を処理することへの2ステップがあります:
1. Check whether the proposed base registration exists in any
bundle. If it does, stop immediately with a failure.
1. 提案されたベース登録が何かバンドルで存在するかどうかチェックしてください。 そうするなら、至急、失敗をふさいでください。
2. Process the base registration with the mechanism described as
"CreateBundle" in Section 6.1, below.
2. 以下のセクション6.1における"CreateBundle"として記述されたメカニズムによるベース登録を処理してください。
Note that the process must be executed only once. The process must not be performed on any output of the process, only on the proposed base registration.
一度だけ過程を実行しなければならないことに注意してください。 過程のどんな出力とも、そして、提案されたベース登録だけに過程を実行してはいけません。
6.1. Description of the CreateBundle Mechanism
6.1. CreateBundleメカニズムの記述
The CreateBundle mechanism determines whether a registration bundle can be created and, if so, populates that bundle with valid labels.
そうだとすれば、そして、CreateBundleメカニズムが、登録バンドルを作成できるかどうか決定する、有効なラベルでそのバンドルに居住します。
During the processing, a "temporary bundle" contains partial labels, that is, labels that are being built and are not complete labels. The partial labels in the temporary bundle consist of strings.
処理の間、「一時的なバンドル」は部分的なラベル(すなわち、建てられていて、完全なラベルでないラベル)を含んでいます。 一時的なバンドルでの部分的なラベルはストリングから成ります。
The steps are:
ステップは以下の通りです。
1. Split the base registration into individual characters, called
"candidate characters". Compare every candidate character
against the base characters in the table. If any candidate
character does not exist in the set of base characters, the
system must stop and not register any names (that is, it must not
register either the base registration or any labels that would
have come from character variants).
1. ベース登録を「候補キャラクタ」と呼ばれる個性に分けてください。 テーブルで基本文字に対してすべての候補キャラクタを比較してください。 何か候補キャラクタが基本文字のセットで存在していないなら、システムは、止まって、どんな名前も登録してはいけません(すなわち、それはキャラクタ異形から来たベース登録かどんなラベルのどちらかも登録してはいけません)。
2. Perform the steps in IDNA's ToASCII sequence for the base
registration. If ToASCII fails for the base registration, the
system must stop and not register any label (that is, it must not
register either the base registration or labels that might have
been created from variants of characters contained in it). If
ToASCII succeeds, place the base registration into the
registration bundle.
2. ベース登録のためにIDNAのToASCII系列におけるステップを実行してください。 ToASCIIがベース登録のために失敗するなら、システムは、止まって、どんなラベルも登録してはいけません(すなわち、それはベース登録かそれに含まれたキャラクタの異形から作成されたかもしれないラベルのどちらかを登録してはいけません)。 ToASCIIが成功するなら、ベース登録を登録バンドルに置いてください。
3. For every candidate character in the base registration, do the
following:
3. ベース登録におけるすべての候補キャラクタには、以下をしてください:
Klensin Informational [Page 21] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[21ページ]のRFC4290IDN登録は2005年12月に練習されます。
o Create the set of characters that consists of the candidate
character and any variants.
o 候補キャラクタとどんな異形からも成るキャラクタのセットを創設してください。
o For each character in the set from the previous step,
duplicate the temporary bundle that resulted from the previous
candidate character, and add the new character to the end of
each partial label.
o 前のステップからのセットにおける各キャラクタには、前の候補キャラクタから生じた一時的なバンドルをコピーしてください、そして、それぞれの部分的なラベルの端への新しいキャラクタを加えてください。
4. The temporary bundle now contains zero or more labels that
consist of Unicode characters. For every label in the temporary
bundle, do the following:
4. 一時的なバンドルは現在、ユニコード文字から成るゼロか、より多くのラベルを含みます。 一時的なバンドルでのあらゆるラベルに関しては、以下をしてください:
o Process the label with ToASCII to see if ToASCII succeeds. If
it does, add the label to the registration bundle. Otherwise,
do not process this label from the temporary bundle any
further; it will not go into the registration bundle.
o ToASCIIと共にラベルを処理して、ToASCIIが成功するかどうか確認してください。 そうするなら、登録バンドルにラベルを加えてください。 さもなければ、一時的なバンドルからこのラベルをこれ以上処理しないでください。 それは登録バンドルに入らないでしょう。
The result of the processing outlined above is the registration bundle with the base registration and possibly other labels.
上に概説された処理の結果はベース登録とことによると他のラベルがある登録バンドルです。
6.2. The "no-variants" Case
6.2. 「異形がありません」ケース
It is clear that, for many scripts, registries will choose to create
tables without variants, either because variants are clearly not
necessary or because they are determined to cause more confusion and
overhead than is justified by the circumstances. For those
situations the table model of Section 5 becomes a trivial listing of
base characters and only the first two steps of CreateBundle
(verifying that all candidate character are in the base ("valid")
character list and verifying that the resulting characters will
succeed in the ToASCII operation) are applicable. Even the second of
those steps becomes pro forma if the advice in the next subsection is
followed.
登録が、多くのスクリプトのために異形なしでテーブルを作成するのを選ぶのは、明確です、異形が明確に必要でないか、または彼らが、より多くの混乱とオーバーヘッドを引き起こすと決心しているので事情によって正当化されるより。 それらの状況のために、セクション5のテーブルモデルは基本文字の些細なリストになります、そして、CreateBundle(すべての候補キャラクタが、ベース(「有効な」)キャラクタリストにあって、結果として起こるキャラクタがToASCII操作に成功することを確かめていることを確かめる)の最初の2ステップだけが適切です。 次の小区分におけるアドバイスが従われているなら、それらのステップの2番目さえ形式上になります。
6.3. CreateBundle and Nameprep Mapping
6.3. CreateBundleとNameprepマッピング
One of the functions of Nameprep, and IDNA more generally, is to map a large number of Unicode characters (code points) into a smaller number to avoid a different but overlapping set of confusion problems. For example, when a non-ASCII script makes distinctions between "upper case" and "lower case", nameprep maps the upper case characters to the lower case ones in order to simulate the DNS protocol's rule that ASCII characters are interpreted in a case- insensitive way. Unicode also contains many code points that are typographic variants on each other (e.g., forms with different widths and code points that designate font variations for mathematical uses), the Unicode standard explicitly identifies them that way, and Nameprep maps these onto base characters.
Nameprep、およびIDNAの機能の1つより一般に、異なりましたが、重なっているセットは避けるより少ない数へのユニコード文字(コード・ポイント)の地図多くへの混乱問題のものですか?例えば、非ASCIIスクリプトが「大文字」と「小文字」の間で分け隔てすると、nameprepは、ASCII文字がケースの神経の鈍い方法で解釈されるというDNSプロトコルの規則をシミュレートするために小文字ものへの大文字キャラクタを写像します。 また、ユニコードは互い(例えば、異なった幅があるフォームと数学の用途のために字体変化を指定するコード・ポイント)の上に印刷の異形である多くのコード・ポイントを含んでいます、そして、ユニコード規格はそのように明らかにそれらを特定します、そして、Nameprepはこれらを基本文字に写像します。
Klensin Informational [Page 22] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[22ページ]のRFC4290IDN登録は2005年12月に練習されます。
While having these mapping functions available during lookup may be quite helpful to users who type equivalent forms, registrations are probably best performed in terms of the IDNA base characters only, i.e., those characters that nameprep will not change. This will have two advantages.
同等な書式をタイプするユーザにとって、ルックアップの間、利用可能なこれらのマッピング機能を持っているのがかなり役立つかもしれない間、登録証明書はたぶんIDNA基本文字だけで最も上手に実行されます、すなわち、nameprepが変えないそれらのキャラクタ。 これには、2つの利点があるでしょう。
o Registrants will never find themselves in the rather confusing
position of having submitted one string for registration and
finding a different string in the registry database (which could
otherwise occur even if the relevant language table does not
contain variants).
o 気付くと、記入者が登録と登録データベース(そうでなければ、関連言語テーブルが異形を含まないでも、起こるかもしれない)で異なったストリングを見つけるために1個のストリングを提出したかなり紛らわしい位置に決していないでしょう。
o Those who are interested in what characters are permitted by a
given registry will only need to examine the relevant tables,
rather than simulating the IDNA algorithm to determine the result
of processing particular characters.
o どんなキャラクタが与えられた登録によって受入れられるかに興味を持っている人は、特定のキャラクタを処理するという結果を決定するためにIDNAアルゴリズムをシミュレートするよりむしろ関連テーブルを調べる必要があるだけでしょう。
7. IANA Considerations
7. IANA問題
Under ICANN (not IETF) direction and management, the IANA has created a registry for language variant tables. The authoritative documentation for that registry is in [IANA-language-registry]. Since the registry exists and is being managed under ICANN direction, the material that follows is a review of the theory of this registry, rather than new instructions for IANA.
ICANN(IETFでない)指示と管理で、IANAは言語異形テーブルのための登録を作成しました。 その登録への正式のドキュメンテーションが[IANA言語登録]にあります。 登録が存在していて、ICANN指示に基づき管理されているので、続く材料はIANAのための新しい指示よりむしろこの登録の理論のレビューです。
As described above and suggested in the JET Guidelines, the registration rules generally require only that:
一般に、上で説明されて、JET Guidelinesに示されるように、登録規則が、以下のことだけが必要です。
o The application be submitted or endorsed by a TLD registry, to
ensure that someone cares about the particular table.
o TLD登録でアプリケーションに提出するか、または裏書きして、それを確実にするために、だれかが特定のテーブルを心配します。
o The table be identified by the following:
o テーブル、以下で、特定されてください:
* the name -- usually the top-level domain name -- of the
submitting or endorsing registry;
* 通常最上位のドメイン名という提出か是認登録の名前。
* one of: a language designation (consistent with [RFC3066] or
with some other system approved by the IANA), a script
designation, a combination of the two, or a sequence number
acceptable to IANA for this purpose;
* 1つ、: 言語名称([RFC3066]かIANAによって承認されるある他のシステムと一致した)、スクリプト名称、2つのものの組み合わせ、またはこの目的のためのIANAに許容できる一連番号。
* a version number; and
* バージョン番号。 そして
* a date.
* 日付。
o Characters listed in the table be identified by Unicode code
points, as discussed above.
o ユニコードコード・ポイントで同じくらい特定されて、上で同じくらい議論していて、キャラクターはテーブルに記載しました。
Klensin Informational [Page 23] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[23ページ]のRFC4290IDN登録は2005年12月に練習されます。
o The table format may correspond to that identified in [RFC3743],
or in Section 5 above, or may be some variation on those themes
appropriate to the local processing model (with or without
variants).
o テーブル形式は、[RFC3743]、または上のセクション5で特定されたそれに対応するかもしれないか、またはローカル処理モデル(異形のあるなしにかかわらず)に、適切なそれらのテーマの何らかの変化であるかもしれません。
This raises some issues that will need to be worked out as experiences accumulate. For example, more standardization of table formats would be desirable to allow processing by the same computer tools for different registries and languages. But standardization seems premature at this time due to differences in languages, processing, and requirements and lack of experience with them. Similarly, if a registry concludes that it should use a table that contains characters from several scripts, it is not clear how such a table should be designated. Identifying it with a language code (either according to [RFC3066] or an independent code registered with IANA) is likely to just introduce more confusion, especially given other Internet uses of the language codes. It appears that some other convention will be needed for those cases, and it should be developed (if it has not already been established by the time this document is published).
これは経験が蓄積するのに従って解決される必要があるいくつかの問題を提起します。 例えば、異なった登録と言語のために同じコンピュータツールで処理するのを許容するのにおいてテーブル形式の、より多くの標準化が望ましいでしょう。 しかし、標準化はこのとき、言語、処理、および要件の違いと経験の欠如のためそれらで時期尚早に見えます。 同様に、登録が、いくつかのスクリプトからキャラクタを含むテーブルを使用するべきであると結論を下すなら、そのようなテーブルがどのように指定されるべきであるかは、明確ではありません。 言語コード([RFC3066]かIANAに示された独立しているコードによると)とそれを同一視するのはただより多くの混乱を導入しそうです、言語コードの他のインターネット用途を特に考えて。 ある他のコンベンションがそれらのケースに必要であり、それが開発されるべきであるように(このドキュメントが発表される時までにそれが既に設立されていないなら)見えます。
8. Internationalization Considerations
8. 国際化問題
This document specifies a model mechanism for registering Internationalized Domain Names (IDNs) that can be used to reduce confusion among similar-appearing names. The proposal is designed to facilitate internationalization while permitting a balance between internationalization concerns and concerns about keeping the Internet global and domain name system references unique in the perception of the user as well as in practice.
このドキュメントは同様の排臨名の中で混乱を抑えるのに使用できるInternationalized Domain Names(IDNs)を登録するのにモデルメカニズムを指定します。 提案は、インターネットをグローバルに保つことに関する国際化心配と心配とユーザの認知と習慣でユニークなドメイン名システム参照の間のバランスを可能にしている間、国際化を容易にするように設計されています。
9. Security Considerations
9. セキュリティ問題
Registration of labels in the DNS that contain essentially
unrestricted sequences of arbitrary Unicode characters may introduce
opportunities for either attacks or simple confusion. Some of these
risks, such as confusion about which character (of several that look
alike) is actually intended, may be associated with the presentation
form of DNS names. Others may be linked to databases associated with
the DNS, e.g., with the difficulty of finding an entry in a "Whois
file" when it is not clear how to enter or to search for the
characters that make up a name. This document discusses a family of
restrictions on the names that can be registered. Restrictions of
the type described can be imposed by a DNS zone ("registry"). The
document also describes some possible tools for implementing such
restrictions.
任意のユニコード文字の本質的には無制限な系列を含むDNSでのラベルの登録は攻撃か簡単な混乱のどちらかの機会を導入するかもしれません。 キャラクタ(同じく見る数個の)が実際に意図する混乱などのこれらのリスクのいくつかがDNS名の表示形に関連しているかもしれません。 他のものはDNSに関連しているデータベースにリンクされるかもしれません、例えば、どのように入るか、または名前を作るキャラクタを捜し求めるかが明確でないときに「Whoisファイル」におけるエントリーを見つけるという困難で。 このドキュメントは登録できる名前で制限の家族について議論します。 DNSゾーン(「登録」)は説明されたタイプの制限を課すことができます。 また、ドキュメントはそのような制限を実行するためのいくつかの可能なツールについて説明します。
Klensin Informational [Page 24] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[24ページ]のRFC4290IDN登録は2005年12月に練習されます。
While the increased number and types of characters made available by
Unicode considerably increases the scale of the potential problems,
the problems addressed by this document are not new. No plausible
set of restrictions will eliminate all problems and sources of
confusion: for example, it has often been pointed out that, even in
ASCII, the characters digit-one ("1") and lower case L ("l") can
easily be confused in some display fonts. But, to the degree to
which security may be aided by sensible risk reduction, these
techniques may be helpful.
増加する数とタイプである間、ユニコードで利用可能にかなりされたキャラクタでは、潜在的な問題、このドキュメントで記述された問題のスケールの増加は新しくはありません。 制限のどんなもっともらしいセットも混乱のすべての問題と源を解決しないでしょう: ケースLを下ろしてください。例えば、それからそれをしばしば指しています、ASCIIでさえ、キャラクタケタ-1、(「1インチ)、(「l」) 容易に、いくつかの表示字体で、混乱できます」。 しかし、セキュリティが分別があるリスク削減で支援されるかもしれない程度に、これらのテクニックは役立っているかもしれません。
10. Acknowledgements
10. 承認
Discussions in the process of developing the JET Guidelines were vital in developing this document and all of the JET participants are consequently acknowledged. Attempts to explain some of the issues uncovered there to, and feedback from, Vint Cerf, Wendy Rickard, and members of the ICANN IDN Committee were also helpful in the thinking leading up to this document.
JET Guidelinesを開発することの途中に議論はこのドキュメントを開発するのにおいて重大でした、そして、その結果、JET関係者のすべてが承認されます。 そこに発見された問題のいくつかに説明する試み、およびフィードバック、また、Vintサーフ、ウェンディー・リカード、およびICANN IDN Committeeのメンバーもこのドキュメントに通じる考えの助けになりました。
An effort by Paul Hoffman to create a generic specification for registration restrictions of this type helped to inspire this document, which takes a somewhat different, more language-oriented, approach than his initial draft. While the initial version of that draft indicated that multiple languages (or multiple language tables) for a single zone were infeasible, more recent versions [Hoffman-reg] shifted to inclusion of language-based approaches. The current version of this document incorporates considerable text, and even more ideas, from those drafts, with Paul Hoffman's generous permission.
このタイプの登録制限のための一般仕様を作成するためのポール・ホフマンによる努力は、彼の初期の草稿よりこのドキュメントを奮い立たせるのを助けました。(ドキュメントはいくらか異なって、より言語指向のアプローチを取ります)。 その草稿の初期のバージョンは、ただ一つのゾーンへの複数の言語(または、複数の言語テーブル)が実行不可能であることを示しましたが、より最近のバージョン[ホフマン-reg]は言語ベースのアプローチの包含に移行しました。 このドキュメントの最新版はかなりのテキスト、およびさらに多くの考えを取り入れます、それらの草稿から、ポール・ホフマンの寛大な許可で。
Feedback was provided by several registry operators (of both country code and generic TLDs), including Edmon Chung and Ram Mohan of Afilias, and by ICANN and IANA staff, notably Tina Dam and Theresa Swinehart. This feedback about issues encountered in registering tables and designing IDN implementations resulted in the addition of significant clarifying text to the current version of the document.
フィードバックはアフィリアスのエドモン・チャンとRamモハンを含む数人の登録オペレータ(国名略号と一般的なTLDsの両方の)、ICANN、IANAスタッフ、著しくティナDam、およびテレサSwinehartによって提供されました。 テーブルを登録して、IDN実現を設計する際に遭遇する問題に関するこのフィードバックは重要なはっきりさせるテキストのドキュメントの最新版への添加をもたらしました。
The opinions expressed here are the sole responsibility of the author. Some of those whose ideas and comments are reflected in this document may disagree with the conclusions the author has drawn from them. The first draft version of this document was posted in June 2003.
ここに述べられた意見は作者の唯一の責任です。 考えとコメントが反映されるそれらのいくつかが本書では作者がそれらから達した結論と意見を異にするかもしれません。 このドキュメントの最初の草案バージョンは2003年6月に掲示されました。
Klensin Informational [Page 25] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[25ページ]のRFC4290IDN登録は2005年12月に練習されます。
11. Informative References
11. 有益な参照
[Daniels] P.T. Daniels and W. Bright, The World's Writing
Systems, Oxford: Oxford University Press: 1996.
[ダニエル]P.T.ダニエルと明るく、世界がシステム、オックスフォードに書くW.: オックスフォード大学出版局: 1996.
[Drucker] Drucker, J., "The Alphabetic Labyrinth: The Letters in
History and Imagination", 1995.
[ドラッカー]ドラッカー、J.、「アルファベット迷路:」 「歴史と想像における手紙」、1995。
[Hoffman-reg] Hoffman, P., "A Method for Registering
Internationalized Domain Names", Work in Progress,
October 2003.
[ホフマン-reg] ホフマン、P.、「国際化ドメイン名を登録するための方法」が進歩、2003年10月に働いています。
[IESG-IDN] Internet Engineering Steering Group, IETF, "IESG
Statement on IDN", IESG Statement available from
http://www.ietf.org/IESG/STATEMENTS/IDNstatement.txt,
February 2003.
[IESG-IDN] インターネットEngineering Steering Group、IETF、「IDNに関するIESG声明」、 http://www.ietf.org/IESG/STATEMENTS/IDNstatement.txt から利用可能なIESG Statement、2003年2月。
[ICANN-IDN] Internet Corporation for Assigned Names and Numbers
(ICANN), "Guidelines for the Implementation of
Internationalized Domain Names, Version 1.0", June
2003.
[ICANN-IDN]アイキャン(ICANN)、「国際化ドメイン名の実現のためのガイドライン、バージョン1インチ、2003年6月。」
[ICANN-IDN2] Internet Corporation for Assigned Names and Numbers
(ICANN), "Guidelines for the Implementation of
Internationalized Domain Names, Version 2.0", September
2005.
[ICANN-IDN2]アイキャン(ICANN)、「国際化ドメイン名の実現のためのガイドライン、バージョン2インチ、2005年9月。」
[IANA-language-registry]
Internet Assigned Numbers Authority (IANA), "IDN
Language Table Registry", April 2004.
[IANA言語登録] インターネットは数の権威(IANA)、「IDN言語テーブル登録」に2004年4月を割り当てました。
[LTRU-Registry]
Phillips, A., Ed. and M. Davis, Ed., "Tags for
Identifying Languages", Work in Progress, October 2005.
エドフィリップス、A.、[LTRU-登録]M.デイヴィス、エド、10月2005、「言語を特定するためのタグ」は進行中で働いています。
[RFC952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD
Internet host table specification", RFC 952, October
1985.
[RFC952] HarrenstienとK.とスタール、M.とE.Feinler、「DoDインターネット・ホストテーブル仕様」、RFC952、1985年10月。
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H.、「言語の識別のためのタグ」、BCP47、RFC3066、2001年1月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
Klensin Informational [Page 26] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[26ページ]のRFC4290IDN登録は2005年12月に練習されます。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)", RFC
3491, March 2003.
[RFC3491] ホフマン、P.、およびM.Blanchet、「Nameprep:」 「国際化ドメイン名(IDN)のためのStringprepプロフィール」、RFC3491、2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of
Unicode for Internationalized Domain Names in
Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]コステロ、A.、「Punycode:」 「Applications(IDNA)のInternationalized Domain Namesのためにユニコードをコード化するBootstring」、RFC3492、2003年3月。
[RFC3536] Hoffman, P., "Terminology Used in Internationalization
in the IETF", RFC 3536, May 2003.
[RFC3536]ホフマン(P.、「IETFでの国際化に使用される用語」、RFC3536)は2003がそうするかもしれません。
[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
Engineering Team (JET) Guidelines for Internationalized
Domain Names (IDN) Registration and Administration for
Chinese, Japanese, and Korean", RFC 3743, April 2004.
[RFC3743] コニシ、K.、ホアン、K.、チエン、H.、およびY.コー、「共同工学は国際化ドメイン名(IDN)登録のための(ジェット)ガイドラインと中国語、日本語、および韓国語のための政権を組にします」、RFC3743、2004年4月。
[Unicode] The Unicode Consortium, "The Unicode Standard --
Version 3.0", January 2000.
[ユニコード] ユニコード共同体、「バージョン3インチ、2000年ユニコード規格--1月。」
[Unicode32] The Unicode Consortium, "Unicode Standard Annex #28:
Unicode 3.2", March 2002.
[Unicode32]ユニコード共同体、「ユニコード規格は#28、を付加します」。 ユニコード3.2インチと、2002年3月。
Author's Address
作者のアドレス
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
Ave、ジョンC Klensin1770マサチューセッツ#322MA02140ケンブリッジ(米国)
Phone: +1 617 491 5735 EMail: john-ietf@jck.com
以下に電話をしてください。 +1 5735年の617 491メール: john-ietf@jck.com
Klensin Informational [Page 27] RFC 4290 IDN Registration Practices December 2005
Klensinの情報[27ページ]のRFC4290IDN登録は2005年12月に練習されます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78とwww.rfc-editor.org/copyright.htmlに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Klensin Informational [Page 28]
Klensin情報です。[28ページ]
一覧
スポンサーリンク
