RFC3743 日本語訳
3743 Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese,Japanese, and Korean. K. Konishi, K. Huang, H. Qian, Y. Ko. April 2004. (Format: TXT=74963 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Konishi
Request for Comments: 3743 K. Huang
Category: Informational H. Qian
Y. Ko
April 2004
コメントを求めるワーキンググループK.コニシの要求をネットワークでつないでください: 3743年のK.ホアンカテゴリ: 情報のH.チエンY.コー2004年4月
Joint Engineering Team (JET) Guidelines for
Internationalized Domain Names (IDN) Registration and
Administration for Chinese, Japanese, and Korean
国際化ドメイン名(IDN)登録のための共同工学チーム(ジェット)ガイドラインと中国語、日本語、および韓国語のための政権
Status of this Memo
この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 (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
IESG Note
IESG注意
The IESG congratulates the Joint Engineering Team (JET) on developing mechanisms to enforce their desired policy. The Language Variant Table mechanisms described here allow JET to enforce language-based character variant preferences, and they set an example for those who might want to use variant tables for their own policy enforcement.
IESGはそれらの必要な方針を実施するためにメカニズムを開発することに関してJoint Engineering Team(JET)を祝います。 JETはここで説明されたLanguage Variant Tableメカニズムで言語ベースのキャラクタ異形好みを実施できます、そして、それらはそれら自身の方針実施に異形テーブルを使用したがっているかもしれない人のために手本を見せます。
The IESG encourages those following this example to take JET's diligence as an example, as well as its technical work. To follow their example, registration authorities may need to articulate policy, develop appropriate procedures and mechanisms for enforcement, and document the relationship between the two. JET's LVT mechanism should be adaptable to different policies, and can be considered during that development process.
IESGは、この例に倣うものが例、およびその技術的な仕事としてJETの勤勉さをみなすよう奨励します。 登録局は、それらの例に倣うために、方針を明確に話すのが必要であり、実施のために適切な手順とメカニズムを開発して、2つの間の関係を記録するかもしれません。 JETのLVTメカニズムは、異なった方針に適合できるべきであり、その開発過程の間、考えることができます。
The IETF does not, of course, dictate policy or require the use of any particular mechanisms for the implementation of these policies, as these are matters of sovereignty and contract.
IETFはこれらの方針の実現のためにもちろん方針を書き取りもしませんし、どんな特定のメカニズムの使用も必要ともしません、これらが主権の問題であり、契約するとき。
Abstract
要約
Achieving internationalized access to domain names raises many complex issues. These are associated not only with basic protocol design, such as how names are represented on the network, compared, and converted to appropriate forms, but also with issues and options for deployment, transition, registration, and administration.
ドメイン名への国際化しているアクセスを達成すると、多くの複雑な問題が提起されます。 これらは名前がどう比べて、ネットワークに表されて、書式を当てるために変換などにされるかなどの基本プロトコルデザインに関連するだけではなく、展開、変遷、登録、および管理のための問題とオプションにも関連しています。
Konishi, et al. Informational [Page 1] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[1ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
The IETF Standards for Internationalized Domain Names, known as "IDNA", focuses on access to domain names in a range of scripts that is broader in scope than the original ASCII. The development process made it clear that use of characters with similar appearances and/or interpretations created potential for confusion, as well as difficulties in deployment and transition. The conclusion was that, while those issues were important, they could best be addressed administratively rather than through restrictions embedded in the protocols. This document defines a set of guidelines for applying restrictions of that type for Chinese, Japanese and Korean (CJK) scripts and the zones that use them and, perhaps, the beginning of a framework for thinking about other zones, languages, and scripts.
"IDNA"として知られているInternationalized Domain NamesのためのIETF Standardsは範囲では、オリジナルのASCIIより広いさまざまなスクリプトによるドメイン名へのアクセスに焦点を合わせます。 開発過程は、同様の外観、そして/または、解釈によるキャラクタの使用が混乱の可能性を作成したと断言しました、展開における困難と変遷と同様に。 結論はそれらの問題が重要であった間制限でプロトコルに埋め込まれているより行政上むしろそれらを記述できたのが最も良いということでした。 このドキュメントは中国の、そして、日本の、そして、韓国の(CJK)文字とそれらを使用するゾーンにそのタイプの制限を適用するためのマニュアル、および他のゾーン、言語、およびスクリプトについて考えるための恐らく枠組みの始まりを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions, Context, and Notation . . . . . . . . . . . . . . 5
2.1. Definitions and Context. . . . . . . . . . . . . . . . . 5
2.2. Notation for Ideographs and Other Non-ASCII CJK
Characters . . . . . . . . . . . . . . . . . . . . . . . 9
3. Scope of the Administrative Guidelines . . . . . . . . . . . . 9
3.1. Principles Underlying These Guidelines . . . . . . . . . 10
3.2. Registration of IDL. . . . . . . . . . . . . . . . . . . 13
3.2.1. Using the Language Variant Table . . . . . . . . 13
3.2.2. IDL Package. . . . . . . . . . . . . . . . . . . 14
3.2.3. Procedure for Registering IDLs . . . . . . . . . 14
3.3. Deletion and Transfer of IDL and IDL Package . . . . . . 19
3.4. Activation and Deactivation of IDL Variants . . . . . . 19
3.4.1. Activation Algorithm . . . . . . . . . . . . . . 19
3.4.2. Deactivation Algorithm . . . . . . . . . . . . . 20
3.5. Managing Changes in Language Associations. . . . . . . . 21
3.6. Managing Changes to Language Variant Tables. . . . . . . 21
4. Examples of Guideline Use in Zones . . . . . . . . . . . . . . 21
5. Syntax Description for the Language Variant Table. . . . . . . 25
5.1. ABNF Syntax. . . . . . . . . . . . . . . . . . . . . . . 25
5.2. Comments and Explanation of Syntax . . . . . . . . . . . 25
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 27
7. Index to Terminology . . . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . 30
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Authors' Addresses . . . . . . . . . . . . . . . . . . . 31
10.2. Editors' Addresses . . . . . . . . . . . . . . . . . . . 32
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 定義、文脈、および記法. . . . . . . . . . . . . . 5 2.1。 定義と文脈。 . . . . . . . . . . . . . . . . 5 2.2. 表意文字と他の非ASCII CJKキャラクター. . . . . . . . . . . . . . . . . . . . . . . 9 3のための記法。 管理ガイドライン. . . . . . . . . . . . 9 3.1の範囲。 これらのガイドライン. . . . . . . . . 10 3.2の基礎となるプリンシプルズ。 IDLの登録。 . . . . . . . . . . . . . . . . . . 13 3.2.1. 言語異形テーブル. . . . . . . . 13 3.2.2を使用します。 IDLパッケージ。 . . . . . . . . . . . . . . . . . . 14 3.2.3. IDLs. . . . . . . . . 14 3.3を登録するための手順。 IDLとIDLの削除と転送は.193.4をパッケージします。 IDL異形. . . . . . 19 3.4.1の起動と非活性化。 起動アルゴリズム. . . . . . . . . . . . . . 19 3.4.2。 非活性化アルゴリズム. . . . . . . . . . . . . 20 3.5。 管理は言語協会で変化します。 . . . . . . . 21 3.6. 管理は言語異形テーブルに変化します。 . . . . . . 21 4. ゾーン. . . . . . . . . . . . . . 21 5でのガイドライン使用に関する例。 言語異形テーブルのための構文記述。 . . . . . . 25 5.1. ABNF構文。 . . . . . . . . . . . . . . . . . . . . . . 25 5.2. 構文. . . . . . . . . . . 25 6に関するコメントと説明。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 27 7. 用語. . . . . . . . . . . . . . . . . . . . . 27 8に索引をつけてください。 承認。 . . . . . . . . . . . . . . . . . . . . . . . 28 9. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.1。 引用規格. . . . . . . . . . . . . . . . . . 29 9.2。 有益な参照. . . . . . . . . . . . . . . . . 30 10。 貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 30 10.1。 作者のアドレス. . . . . . . . . . . . . . . . . . . 31 10.2。 エディタのアドレス. . . . . . . . . . . . . . . . . . . 32 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 33
Konishi, et al. Informational [Page 2] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[2ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
1. Introduction
1. 序論
Domain names form the fundamental naming architecture of the Internet. Countless Internet protocols and applications rely on them, not just for stability and continuity, but also to avoid ambiguity. They were designed to be identifiers without any language context. However, as domain names have become visible to end users through Web URLs and e-mail addresses, the strings in domain-name labels are being increasingly interpreted as names, words, or phrases. It is likely that users will do the same with languages of differing character sets, such as Chinese, Japanese and Korean (CJK), in which many words or concepts are represented using short sequences of characters.
ドメイン名はインターネットの基本的な命名構造を形成します。 また、無数のインターネットプロトコルとアプリケーションは、安定性と連続だけ、当てにするのではなく、あいまいさを避けるためにそれらを当てにします。 それらは、少しも言語文脈がなければ識別子になるように設計されました。 しかしながら、ドメイン名がウェブURLとEメールアドレスを通してエンドユーザにとって目に見えるようになったとき、ドメイン名ラベルのストリングはますます名前、単語、または句として解釈されています。 ユーザは同じように異なった文字の組の用語を処理しそうでしょう、中国語や、日本語や韓国語(CJK)などのように。(多くの言葉か概念が、それでキャラクタの短い系列を使用することで表されます)。
The introduction of what are called Internationalized Domain Names (IDN) amplifies both the difficulty of putting names into identifiers and the confusion that exists between scripts and languages. Character symbols that appear (or actually are) identical, or that have similar or identical semantics but that are assigned the different code points, further increase the potential for confusion. DNS internationalization also affects a number of Internet protocols and applications and creates additional layers of complexity in terms of technical administration and services. Given the added complications of using a much broader range of characters than the original small ASCII subset, precautions are necessary in the deployment of IDNs in order to minimize confusion and fraud.
Internationalized Domain Names(IDN)と呼ばれるものに関する序論は識別子に名前を入れるという困難とスクリプトと言語の間に存在する混乱の両方を増幅します。 同じに見えるか(または、実際に、あります)、同様の、または、同じ意味論を持っていますが、または異なったコード・ポイントが割り当てられるキャラクターシンボルは混乱の可能性をさらに増加させます。 DNS国際化は、また、多くのインターネットプロトコルとアプリケーションに影響して、技術的な管理とサービスで追加層の複雑さを作成します。 オリジナルの小さいASCII部分集合よりはるかに広い範囲のキャラクタを使用する加えられた複雑さを考えて、注意が、混乱と詐欺を最小にするのにIDNsの展開で必要です。
The IETF IDN Working Group [IDN-WG] addressed the problem of handling the encoding and decoding of Unicode strings into and out of Domain Name System (DNS) labels with the goal that its solution would not put the operational DNS at any risk. Its work resulted in one primary protocol and three supporting ones, respectively:
IETF IDN作業部会[IDN-WG]はラベルの中と、そして、目標があるドメインネームシステム(DNS)ラベルからユニコードストリングのコード化と解読を扱うという解決策がどんな危険を冒しても操作上のDNSを置かないだろうというその問題を訴えました。 仕事は1つの第一のプロトコルとそれぞれものを支持する3をもたらしました:
1. Internationalizing Host Names in Applications [IDNA]
2. Preparation of Internationalized Strings [STRINGPREP]
3. A Stringprep Profile for Internationalized Domain Names
[NAMEPREP]
4. Punycode [PUNYCODE]
1. ホストを国際的にすると、アプリケーションでは、[IDNA]2は命名されます。 国際化することの準備は[STRINGPREP]3を結びます。 国際化ドメイン名[NAMEPREP]4のためのStringprepプロフィール。 Punycode[PUNYCODE]
IDNA, which calls on the others, normalizes and transforms strings that are intended to be used as IDNs. In combination, the four provide the minimum functions required for internationalization, such as performing case mappings, eliminating character differences that would cause severe problems, and specifying matching (equality). They also convert between the resulting Unicode code points and an ASCII-based form that is more suitable for storing in actual DNS labels. In this way, the IDNA transformations improve a user's chances of getting to the correct IDN.
IDNA(他のものを訪問する)はIDNsとして使用されることを意図するストリングを、正常にして、変えます。 組み合わせように、4は国際化に必要である最小の機能を提供します、ケースマッピングを実行するのなどように、厳しい問題を引き起こすキャラクタ差を排除して、合っている(平等)を指定して。 また、彼らは結果として起こるユニコードコード・ポイントと実際のDNSにラベルを格納するのにより適当なASCIIベースの用紙の間で変換します。 このように、IDNA変化は正しいIDNを始めるというユーザの可能性を改良します。
Konishi, et al. Informational [Page 3] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[3ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
Addressing the issues around differing character sets, a primary consideration and administrative challenge involves region-specific definitions, interpretations, and the semantics of strings to be used in IDNs. A Unicode string may have a specific meaning as a name, word, or phrase in a particular language but that meaning could vary depending on the country, region, culture, or other context in which the string is used. It might also have different interpretations in different languages that share some or all of the same characters. Therefore, individual zones and zone administrators may find it necessary to impose restrictions and procedures to reduce the likelihood of confusion, and instabilities of reference, within their own environments.
異なった文字の組、第一の考慮、および管理挑戦の周りに問題を記述すると、ストリングの領域特有の定義、解釈、および意味論は、IDNsで使用されるためにかかわります。 ユニコードストリングには、ストリングが使用されている国、領域、文化、または他の文脈によって、特定の言語にもかかわらず、その意味における名前、単語、または句が異なることができたように特定の意味があるかもしれません。 また、それは同じキャラクタのいくつかを共有する異なった言語かすべてに異なった解釈を持っているかもしれません。 したがって、個々のゾーンとゾーンの管理者は、混乱の見込み、および参照の不安定性を減少させるのが制限と手順を課すのに必要であることがわかるかもしれません、それら自身の環境の中で。
Over the centuries, the evolution of CJK characters, and the differences in their use in different languages and even in different regions where the same language is spoken, has given rise to the idea of "variants", wherein one conceptual character can be identified with several different Code Points in character sets for computer use. This document provides a framework for handling such variants while minimizing the possibility of serious user confusion in the obtaining or using of domain names. However, the concept of variants is complex and may require many different layers of solutions. This guideline offers only one of those solution components. It is not sufficient by itself to solve the whole problem, even with zone- specific tables as described below.
世紀には、CJK文字の発展、および同じ言語が話される異なった言語と異なった領域さえでの彼らの使用の違いは1つの概念的な性格を同一視できる数個の異なったCode Pointsがぴったりしたコンピュータ使用に設定する「異形」の考えを起こしています。 このドキュメントはドメイン名の入手か使用における、重大なユーザ混乱の可能性を最小にしている間、そのような異形を扱うのに枠組みを提供します。 しかしながら、異形の概念は、複雑であり、多くの異なった層の溶液を必要とするかもしれません。 このガイドラインはそれらの解決策コンポーネントの1つだけを提供します。 全体の問題を解決するのはそれ自体で以下で説明されるゾーンの特定のテーブルがあっても十分ではありません。
Additionally, because of local language or writing-system differences, it is impossible to create universally accepted definitions for which potential variants are the same and which are not the same. It is even more difficult to define a technical algorithm to generate variants that are linguistically accurate. That is, that the variant forms produced make as much sense in the language as the originally specified forms. It is also possible that variants generated may have no meaning in the associated language or languages. The intention is not to generate meaningful "words" but to generate similar variants to be reserved. So even though the method described in this document may not always be linguistically accurate, nor does it need to be, it increases the chances of getting the right variants while accepting the inherent limitations of the DNS and the complexities of human language.
さらに、現地語か書記体系差のために、潜在的異形が同じ、そして、同じでない一般に受け入れられた定義を作成するのは不可能です。 言語学的に正確な異形を発生させるように技術的なアルゴリズムを定義するのはさらに難しいです。 発生した異型は元々指定されたフォームとして言語の同じくらい多くの意味になります。すなわち、また、発生する異形が関連言語か言語の意味でないのを持っているのも、可能です。 意志は重要な「単語」を発生させるのではなく、予約されるために同様の異形を発生させることです。 本書では説明された方法はそうしないかもしれませんが、したがって、いつも言語学的に正確にしてください、そして、高める必要はありません。いてください、そして、それはDNSの固有の限界を受け入れている間、正しい異形を得るという可能性と人間の言語の複雑さを高めます。
This document outlines a model for such conventions for zones in which labels that contain CJK characters are to be registered and a system for implementing that model. It provides a mechanism that allows each zone to define its own local rules for permitted characters and sequences and the handling of IDNs and their variants.
このドキュメントはCJK文字を含むラベルが登録されていることになっているゾーンとそのモデルを実行するシステムのためにそのようなコンベンションのモデルについて概説します。 それは各ゾーンが受入れられたキャラクタと系列のためにそれ自身のローカル・ルールを定義できるメカニズムとIDNsと彼らの異形の取り扱いを提供します。
Konishi, et al. Informational [Page 4] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[4ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
The document is an effort of the Joint Engineering Team (JET), a group composed of members of CNNIC, TWNIC, KRNIC, and JPNIC as well as other individual experts. It offers guidelines for zone administrators, including but not limited to registry operators and registrars and information for all domain names holders on the administration of domain names that contain characters drawn from Chinese, Japanese, and Korean scripts. Other language groups are encouraged to develop their own guidelines as needed, based on these guidelines if that is helpful.
ドキュメントは、他の個々の専門家と同様にJoint Engineering Teamの努力(JET)と、CNNICのメンバーで構成されたグループと、TWNICと、KRNICと、JPNICです。 それはゾーンの管理者のためにガイドラインを提供します、中国の、そして、日本の、そして、韓国の文字から得られたキャラクタを含むドメイン名の管理のすべてのドメイン名所有者への他の登録オペレータ、記録係、および情報を含んでいて。 それが役立っているなら、他の言語グループがこれらのガイドラインに基づいて必要であるそれら自身のガイドラインを開発するよう奨励されます。
2. Definitions, Context, and Notation
2. 定義、文脈、および記法
2.1. Definitions and Context
2.1. 定義と文脈
This document uses a number of special terms. In this section, definitions and explanations are grouped topically. Some readers may prefer to skip over this material, returning, perhaps via the index to terminology in section 7, when needed.
このドキュメントは多くの特別な用語を使用します。このセクションでは、定義と説明は話題として分類されます。 何人かの読者が、この材料を飛ばすのを好むかもしれません、戻ります、恐らくセクション7の用語へのインデックスで、必要であると。
2.1.1. IDN
2.1.1. IDN
IDN: The term "IDN" has a number of different uses: (a) as an abbreviation for "Internationalized Domain Name"; (b) as a fully qualified domain name that contains at least one label that contains characters not appearing in ASCII, specifically not in the subset of ASCII recommended for domain names (the so-called "hostname" or "LDH" subset, see RFC1035 [STD13]); (c) as a label of a domain name that contains at least one character beyond ASCII; (d) as a Unicode string to be processed by Nameprep; (e) as a string that is an output from Nameprep; (f) as a string that is the result of processing through both Nameprep and conversion into Punycode; (g) as the abbreviation of an IDN (more properly, IDL) Package, in the terminology of this document; (h) as the abbreviation of the IETF IDN Working Group; (g) as the abbreviation of the ICANN IDN Committee; and (h) as standing for other IDN activities in other companies/organizations.
IDN: "IDN"という用語には、多くの異なった用途があります: (a) 「国際化ドメイン名」のための略語として。 (b) 特にドメイン名のために推薦されたASCIIの部分集合でないのにASCIIに現れないキャラクタを含む少なくとも1個のラベルを含む完全修飾ドメイン名、(いわゆる「ホスト名」か"LDH"部分集合、RFC1035[STD13)を見てください。 (c) ドメイン名のラベルとして、それはASCIIを超えて少なくとも1文字を含んでいます。 (d) Nameprepによって処理されるべきユニコードストリングとして。 (e) ストリングとして、それはNameprepからの出力です。 (f) ストリングとして、それはNameprepと変換のPunycodeへの両方を通した処理の結果です。 (g) IDNの略語、(より適切である、IDL) このドキュメントの用語のパッケージ。 (h) IETF IDN作業部会の略語として。 (g) ICANN IDN Committeeの略語として。 そして、他の会社/組織における他のIDN活動を表すとしての(h)。
Because of the potential confusion, this document uses the term "IDN" as an abbreviation for Internationalized Domain Name and, specifically, in the second sense described in (b) above. It uses "IDL," defined immediately below, to refer to Internationalized Domain Labels.
潜在的混乱のために、国際化ドメイン名と特に2番目の意味における略語が上で(b)で説明したようにこのドキュメントは"IDN"という用語を使用します。 それは、国際化しているドメインラベルについて言及するのにすぐに以下で定義された"IDL"を使用します。
2.1.2. IDL
2.1.2. IDL
IDL: This document provides a guideline to be applied on a per-zone basis, one label at a time. Therefore, the term "Internationalized Domain Label" or "IDL" will be used instead of the more general term "IDN" or its equivalents. The processing specifications of this
IDL: このドキュメントは、1ゾーンあたり1つの基礎、時間の1個のラベルに適用されるためにガイドラインを提供します。 したがって、用語が「ドメインラベルを国際的にした」か、または"IDL"は"IDN"というより一般的な用語かその同等物の代わりに使用されるでしょう。 この処理仕様
Konishi, et al. Informational [Page 5] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[5ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
document may be applied, in some zones, to ASCII characters also, if those characters are specified as valid in a Language Variant Table (see below). Hence, in some zones, an IDL may contain or consist entirely of "LDH" characters.
ドキュメントは適用されるかもしれません、いくつかのゾーンで、ASCII文字にも、それらのキャラクタがLanguage Variant Tableで有効であるとして指定されるなら(以下を見てください)。 したがって、いくつかのゾーンでは、IDLが含むかもしれませんか、または"LDH"キャラクタから完全に成ってください。
2.1.3. FQDN
2.1.3. FQDN
FQDN: A fully qualified domain name, one that explicitly contains all labels, including a Top-Level Domain (TLD) name. In this context, a TLD name is one whose label appears in a nameserver record in the root zone. The term "Domain Name Label" refers to any label of a FQDN.
FQDN: 完全修飾ドメイン名、明らかにTop-レベルDomain(TLD)名を含むすべてのラベルを含むもの。 このような関係においては、TLD名はラベルがルートゾーンでのネームサーバ記録に現れるものです。 「ドメイン名ラベル」という用語はFQDNのどんなラベルについても言及します。
2.1.4. Registrations
2.1.4. 登録証明書
Registration: In this document, the term "registration" refers to the process by which a potential domain name holder requests that a label be placed in the DNS either as an individual name within a domain or as a subdomain delegation from another domain name holder. In the case of a successful registration, the label or delegation records are placed in the relevant zone file, or, more specifically, they are "activated" or made "active" and additional IDLs may be reserved as part of an "IDL Package" (see below). The guidelines presented here are recommended for all zones, at any hierarchy level, in which CJK characters are to appear and not just domains at the first or second level.
登録: 本書では、「登録」という用語は別のドメイン名所有者から潜在的ドメイン名所有者が、ラベルがドメインの中の個人名として、または、サブドメインの移譲としてDNSに置かれるよう要求する過程を示します。 より明確に、それらを「動かす」か、または「アクティブに」します、そして、うまくいっている登録の場合では、ラベルか代表団記録を関連ゾーンファイルに置くか、または「IDLパッケージ」の一部として追加IDLsを予約するかもしれません(以下を見てください)。 ここに提示されたガイドラインはすべてのゾーンに推薦されます、1番目か第2レベルにおけるドメインだけではなく、どんな階層構造レベルでも。そこでは、CJK文字が現れることになっています。
2.1.5. RFC3066
2.1.5. RFC3066
RFC3066: A system, widely used in the Internet, for coding and representing names of languages [RFC3066]. It is based on an International Organization for Standardization (ISO) standard for coding language names [ISO639], but expands it to provide additional precision.
RFC3066: 言語[RFC3066]の名前をコード化して、表すのにインターネットで広く使用されるシステム。 それは、コード化言語名[ISO639]の国際標準化機構(ISO)規格に基づいていますが、追加精度を提供するためにそれを広げます。
2.1.6. ISO/IEC 10646
2.1.6. ISO/IEC10646
ISO/IEC 10646: The international standard universal multiple-octet
coded character set ("UCS") [IS10646]. The Code Point definitions of
this standard are identical to those of corresponding versions of the
Unicode standard (see below). Consequently, the characters and their
coding are often referred to as "Unicode characters."
ISO/IEC10646: 世界規格の普遍的な複数の八重奏は文字の組(「UCS」)[IS10646]をコード化しました。 この規格のCode Point定義はユニコード規格の対応するバージョンのものと同じです(以下を見てください)。 その結果、キャラクタと彼らのコード化はしばしば「ユニコード文字」と呼ばれます。
2.1.7. Unicode Character
2.1.7. ユニコードキャラクター
Unicode Character: The term "Unicode character" is used here in reference to characters chosen from the Unicode Standard Version 3.2 [UNICODE] (and hence from ISO/IEC 10646). In this document, the
ユニコードキャラクター: 「ユニコード文字」という用語がここでユニコードStandardバージョン3.2[ユニコード]から選ばれたキャラクタに関して使用される、(したがって、ISO/IEC10646) このドキュメントで
Konishi, et al. Informational [Page 6] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[6ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
characters are identified by their positions, or "Code Points." The notation U+12AB, for example, indicates the character at the position 12AB (hexadecimal) in the Unicode 3.2 table. For characters in positions above FFFF, i.e., requiring more than sixteen bits to represent, a five to eight-character string is used, such as U+112AB for the character in position 12AB of plane 1.
キャラクタは彼らの位置、または「コード・ポイント」によって特定されます。 例えば、記法U+12ABは位置の12AB(16進)で3.2が見送るユニコードでキャラクタを示します。 すなわち、FFFFの上の位置のキャラクタ、表す16ビット以上の必要さにおいて、8文字列への5は使用されています、飛行機1の位置の12ABのキャラクタのためのU+112ABなどのように。
2.1.8. Unicode String
2.1.8. ユニコードストリング
Unicode String: "Unicode string" refers to a string of Unicode characters. The Unicode string is identified by the sequence of the Unicode characters regardless of the encoding scheme.
ユニコードストリング: 「ユニコードストリング」は一連のユニコード文字を示します。 ユニコードストリングはコード化計画にかかわらずユニコード文字の系列によって特定されます。
2.1.9. CJK Characters
2.1.9. CJKキャラクター
CJK Characters: CJK characters are characters commonly used in the Chinese, Japanese, or Korean languages, including but not limited to those defined in the Unicode Standard as ASCII (U+0020 to U+007F), Han ideographs (U+3400 to U+9FAF and U+20000 to U+2A6DF), Bopomofo (U+3100 to U+312F and U+31A0 to U+31BF), Kana (U+3040 to U+30FF), Jamo (U+1100 to 11FF and U+3130 to U+318F), Hangul (U+AC00 to U+D7AF and U+3130 to U+318F), and the respective compatibility forms. The particular characters that are permitted in a given zone are specified in the Language Variant Table(s) for that zone.
CJKキャラクター: CJK文字は中国の、または、日本の、または、韓国の言語で一般的に使用されるキャラクタです、ものがユニコードStandardでASCII(U+007FへのU+0020)、ハン表意文字(U+9FAFへのU+3400とU+2A6DFへのU+20000)、Bopomofo(U+31BFへのU+312FとU+31A0へのU+3100)、Kana(U+30FFへのU+3040)、Jamo(11FFへのU+1100とU+318FへのU+3130)、ハングル(U+D7AFへのU+AC00とU+318FへのU+3130)、およびそれぞれの互換性用紙と定義した他を含んでいて; 与えられたゾーンで受入れられる特定のキャラクタはLanguage Variant Table(s)でそのゾーンに指定されます。
2.1.10. Label String
2.1.10. ラベルストリング
Label String: A generic term referring to a string of characters that is a candidate for registration in the DNS or such a string, once registered. A label string may or may not be valid according to the rules of this specification and may even be invalid for IDNA use. The term "label", by itself, refers to a string that has been validated and may be formatted to appear in a DNS zone file.
ストリングをラベルしてください: いったん登録されるとDNSかそのようなストリングにおける登録の候補である一連のキャラクタについて言及する総称。 ラベルストリングは、この仕様の規則に従って有効であるかもしれなく、IDNA使用に、無効でさえあるかもしれません。 「ラベル」という用語は、それ自体で有効にされたストリングについて言及して、DNSゾーンファイルに現れるようにフォーマットされるかもしれません。
2.1.11. Language Variant Table
2.1.11. 言語異形テーブル
Language Variant Table: The key mechanisms of this specification utilize a three-column table, called a Language Variant Table, for each language permitted to be registered in the zone. Those columns are known, respectively, as "Valid Code Point", "Preferred Variant", and "Character Variant", which are defined separately below. The Language Variant Tables are critical to the success of the guideline described in this document. However, the principles to be used to generate the tables are not within the scope of this document and should be worked out by each registry separately (perhaps by adopting or adapting the work of some other registry). In this document, "Table" and "Variant Table" are used as short forms for Language Variant Table.
言語異形テーブル: Language Variant Tableは、この仕様の主要なメカニズムが3コラムのテーブルを利用すると呼びました、ゾーンに登録されることが許可された各言語のために。 それらのコラムは別々に以下で定義される「有効なコード・ポイント」、「都合のよい異形」、および「キャラクター異形」としてそれぞれ知られています。 Language Variant Tablesは本書では説明されたガイドラインの成功に重要です。 しかしながら、テーブルを発生させるのに使用されるべき原則は、このドキュメントの範囲の中になくて、別々に各登録によって解決されるべきです(恐らく、ある他の登録の仕事を採用するか、または適合させることによって)。 本書では、「テーブル」と「異形テーブル」はLanguage Variant Tableに縮約形として使用されます。
Konishi, et al. Informational [Page 7] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[7ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
2.1.12. Valid Code Point
2.1.12. 有効なコード・ポイント
Valid Code Point: In a Language Variant Table, the list of Code Points that is permitted for that language. Any other Code Points, or any string containing them, will be rejected by this specification. The Valid Code Point list appears as the first column of the Language Variant Table.
有効なコード・ポイント: Language Variant Table、その言語のために受入れられるCode Pointsのリストで。 いかなる他のCode Points、または彼らを含むどんなストリングもこの仕様で拒絶されるでしょう。 Valid Code PointリストはLanguage Variant Tableの最初のコラムとして現れます。
2.1.13. Preferred Variant
2.1.13. 都合のよい異形
Preferred Variant: In a Language Variant Table, a list of Code Points corresponding to each Valid Code Point and providing possible substitutions for it. These substitutions are "preferred" in the sense that the variant labels generated using them are normally registered in the zone file, or "activated." The Preferred Code Points appear in column 2 of the Language Variant Table. "Preferred Code Point" is used interchangeably with this term.
都合のよい異形: Language Variant Table、各Valid Code Pointに対応する可能な代替をそれに提供しているCode Pointsのリストで。 これらの代替は、通常、それらを使用することで発生する異形ラベルがゾーンファイルに登録されるという意味で「好まれる」か、または「動かされます」。 Preferred Code PointsはLanguage Variant Tableに関するコラム2に現れます。 「都合のよいCode Point」は今期と共に互換性を持って使用されます。
2.1.14. Character Variant
2.1.14. キャラクター異形
Character Variant: In a Language Variant Table, a second list of Code Points corresponding to each Valid Code Point and providing possible substitutions for it. Unlike the Preferred Variants, substitutions based on Character Variants are normally reserved but not actually registered (or "activated"). Character Variants appear in column 3 of the Language Variant Table. The term "Code Point Variants" is used interchangeably with this term.
キャラクター異形: Language Variant Table、各Valid Code Pointに対応する可能な代替をそれに提供しているCode Pointsの2番目のリストで。 Preferred Variantsと異なって、キャラクターVariantsに基づく代替は、通常予約されますが、実際に登録されません(または、「動かされます」)。 キャラクターVariantsはLanguage Variant Tableに関するコラム3に現れます。 「コード・ポイント異形」という用語は今期と共に互換性を持って使用されます。
2.1.15. Preferred Variant Label
2.1.15. 都合のよい異形ラベル
Preferred Variant Label: A label generated by use of Preferred Variants (or Preferred Code Points).
都合のよい異形ラベル: Preferred Variants(または、Preferred Code Points)の使用で発生するラベル。
2.1.16. Character Variant Label
2.1.16. キャラクター異形ラベル
Character Variant Label: A label generated by use of Character Variants.
キャラクター異形ラベル: キャラクターVariantsの使用で発生するラベル。
2.1.17. Zone Variant
2.1.17. ゾーン異形
Zone Variant: A Preferred or Character Variant Label that is actually to be entered (registered) into the DNS. That is, into the zone file for the relevant zone. Zone Variants are also referred to as Zone Variant Labels or Active (or Activated) Labels.
ゾーン異形: 実際にDNSに入れられることになっている(登録されます)PreferredかキャラクターVariant Label。 すなわち、ゾーンに、関連ゾーンを申し込んでください。 また、ゾーンVariantsはZone Variant LabelsかActive(または、Activated)ラベルと呼ばれます。
Konishi, et al. Informational [Page 8] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[8ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
2.1.18. IDL Package
2.1.18. IDLパッケージ
IDL Package: A collection of IDLs as determined by these Guidelines. All labels in the package are "reserved", meaning they cannot be registered by anyone other than the holder of the Package. These reserved IDLs may be "activated", meaning they are actually entered into a zone file as a "Zone Variant". The IDL Package also contains identification of the language(s) associated with the registration process. The IDL and its variant labels form a single, atomic unit.
IDLは以下をパッケージします。 これらのGuidelinesで同じくらい断固としたIDLsの収集。 パッケージの中のすべてのラベルが「予約されています」、パッケージの所有者以外のだれもそれらを登録できないことを意味して。 彼らが実際に「ゾーン異形」としてゾーンファイルの中に入れられることを意味して、これらの予約されたIDLsは「動かされるかもしれません」。 また、IDLパッケージは登録手続に関連している言語の識別を含んでいます。 IDLとその異形ラベルは単一の、そして、原子力の単位を形成します。
2.2. Notation for Ideographs and Other Non-ASCII CJK Characters.
2.2. 表意文字と他の非ASCII CJKキャラクターのための記法。
For purposes of clarity, particularly in regard to examples, Han ideographs appear in several places in this document. However, they do not appear in the ASCII version of this document. For the convenience of readers of the ASCII version, and some readers not familiar with recognizing and distinguishing Chinese characters, most uses of these characters will be associated with both their Unicode Code Points and an "asterisk tag" with its corresponding Chinese Romanization [ISO7098], with the tone mark represented by a number from 1 to 4. Those tags have no meaning outside this document; they are a quick visual and reading reference to help facilitate the combinations and transformations of characters in the guideline and table excerpts.
明快の目的と、特に例に関して、ハン表意文字は方々に本書では現れます。 しかしながら、彼らはこのドキュメントのASCII版に現れません。 ASCII版の読者、および漢字を認識して、区別するのに詳しくない何人かの読者の都合のために、対応する中国のローマ化[ISO7098]でこれらのキャラクタのほとんどの用途が彼らのユニコードCode Pointsと「アスタリスクタグ」の両方に関連するでしょう、トーンマークが数によって1〜4まで表されている状態で。 それらのタグはこのドキュメントの外に意味を持っていません。 それらは、ガイドラインの、キャラクタの組み合わせと変化を容易にするのを助ける視覚と読み込みの迅速な参照とテーブル抜粋です。
3. Scope of the Administrative Guidelines
3. 管理ガイドラインの範囲
Zone administrators are responsible for the administration of the domain name labels under their control. A zone administrator might be responsible for a large zone, such as a top-level domain (TLD), whether generic or country code, or a smaller one, such as a typical second- or third-level domain. A large zone is often more complex than its smaller counterpart. However, actual technical administrative tasks, such as addition, deletion, delegation, and transfer of zones between domain name holders, are similar for all zones.
ゾーンの管理者は彼らのコントロールの下においてドメイン名ラベルの管理に責任があります。 ゾーンの管理者は大きいゾーンに責任があるかもしれません、最上位のドメイン(TLD)のように、ジェネリック、国名略号、または、より小さいものであることにかかわらず、典型的な2番目か第3レベルドメインのように。 大きいゾーンは、より小さい対応者よりしばしば複雑です。 しかしながら、すべてのゾーンに、添加などの実際の技術的な管理業務(ドメイン名所有者の間のゾーンの削除、代表団、および転送)は、同様です。
This document provides guidelines for the ways CJK characters should be handled within a zone, for how language issues should be considered and incorporated, and for how Domain Name Labels containing CJK characters should be administered (including registration, deletion, and transfer of labels).
このドキュメントはCJK文字がゾーンの中で扱われるべき方法と、CJK文字を含むDomain Name Labelsが言語問題が考えられてどう法人組織であるべきであるか、そして、どう管理されるべきであるかガイドラインを提供します(ラベルの登録、削除、および転送を含んでいて)。
Other IDN policies, such as the creation of new top-level domains (TLDs), the cost structure for registrations, and how the processes described here get allocated between registrar and registry if the zone makes that distinction, also are outside the scope of this document.
また、このドキュメントの範囲の外に新しい最上位のドメイン(TLDs)の創造などの他のIDN方針(登録証明書と、ゾーンがそれを区別にするならどうここで説明された過程を記録係と登録の間に割り当てるか原価構造)があります。
Konishi, et al. Informational [Page 9] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[9ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
Technical implementation issues are not discussed here either. For example, deciding which guidelines should be implemented as registry actions and which should be registrar actions is left to zone administrators, with the possibility that it will differ from zone to zone.
ここで技術的実装問題について議論しません。 例えば、どのガイドラインが登録動作として実行されるべきであるか、そして、どれが記録係動作であるべきであるかを決めるのをゾーンの管理者に任せます、ゾーンからゾーンまで異なる可能性で。
3.1. Principles Underlying These Guidelines
3.1. これらのガイドラインの基礎となるプリンシプルズ
In many places, in the event of a dispute over rights to a name (or, more accurately, DNS label string), this document assumes "first- come, first-served" (FCFS) as a resolution policy even though FCFS is not listed below as one of the principles for this document. If policies are already in place governing priorities and "rights", one can use the guidelines here by replacing uses of FCFS in this document with policies specific to the zone. Some of the guidelines here may not be applicable to other policies for determining rights to labels. Still other alternatives, such as use of UDRP [UDRP] or mutual exclusion, might have little impact on other aspects of these guidelines.
異義が生じた場合には多くの場所と、名前(より正確に、DNSはストリングをラベルする)への権利の上に関して、FCFSですが、解決方針がこのドキュメントのための原則の1つとして以下に記載されていないようにこのドキュメントは、「1番目は、来て、最初に、役立った」(FCFS)と仮定します。 方針がプライオリティと「権利」を決定しながら既に適所にあるなら、1つは、ここで本書ではFCFSの用途をゾーンに特定の方針に取り替えることによって、ガイドラインを使用できます。 ここのガイドラインのいくつかがラベルへの権利を決定するための他の方針に適切でないかもしれません。 UDRP[UDRP]か相互排除の使用などのまだ他の代替手段はこれらのガイドラインの他の局面で少ししか影響を与えさせないかもしれません。
(a) Although some Unicode strings may be pure identifiers made up of an assortment of characters from many languages and scripts, IDLs are likely to be "words" or "names" or "phrases" that have specific meaning in a language. While a zone administration might or might not require "meaning" as a registration criterion, meaning could prove to be a useful tool for avoiding user confusion.
(a) いくつかのユニコードストリングが多くの言語とスクリプトからキャラクタの分類で作られた、純粋な識別子であるかもしれませんが、IDLsは言語の特定の意味を持っている「単語」、「名前」または「句」である傾向があります。 ゾーン管理は、必要である、または登録評価基準として「意味すること」を必要としないかもしれませんが、意味はユーザ混乱を避けるための有益な手段であると判明できました。
Each IDL to be registered should be associated administratively
with one or more languages.
それぞれの登録されるべきIDLは行政上1つ以上の言語に関連しているべきです。
Language associations should either be predetermined by the zone administrator and applied to the entire zone or be chosen by the registrants on a per-IDL basis. The latter may be necessary for some zones, but it will make administration more difficult and will increase the likelihood of conflicts in variant forms.
言語協会は、ゾーンの管理者によって予定されて、全体のゾーンに適用されるはずであるか、または1IDLあたり1個のベースの記入者によって選ばれるはずです。 後者がいくつかのゾーンに必要であるかもしれませんが、それは、管理をより難しくして、異型における闘争の可能性を広げるでしょう。
A given zone might have multiple languages associated with it or it may have no language specified at all. Omitting specification of a language may provide additional opportunities for user confusion and is therefore NOT recommended.
与えられたゾーンには、それに関連している複数の言語があるかもしれませんか、またはそれは言語を全く指定しないかもしれません。 言語の仕様を省略するのは、ユーザ混乱の追加の機会を提供するかもしれなくて、したがって、推薦されません。
(b) Each language uses only a subset of Unicode characters. Therefore, if an IDL is associated with a language, it is not permitted to contain any Unicode character that is not within the valid subset for that language.
(b) 各言語はユニコード文字の部分集合だけを使用します。 したがって、IDLが言語に関連しているなら、その言語のための有効な部分集合の中にいない少しのユニコード文字も含むことが許可されません。
Each IDL to be registered must be verified against the valid
subset of Unicode for the language(s) associated with the IDL.
IDLに関連している言語のためにユニコードの有効な部分集合に対して各登録されるべきIDLについて確かめなければなりません。
Konishi, et al. Informational [Page 10] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[10ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
That subset is specified by the list of characters appearing in
the first column of the language and zone-specific tables as
described later in this document.
その部分集合は言語とゾーン特有のテーブルの最初のコラムで本書では後述のように見えるキャラクタのリストによって指定されます。
If the IDL fails this test for any of its associated languages, the IDL is not valid for registration.
IDLが関連言語のどれかのためにこのテストに失敗するなら、登録には、IDLは有効ではありません。
Note that this verification is not necessarily linguistically accurate, because some languages have special rules. For example, some languages impose restrictions on the order in which particular combinations of characters may appear. Characters that are valid for the language, and hence permitted by this specification, might still not form valid words or even strings in the language.
いくつかの言語には特別な規則があるので、この検証が必ず言語学的に正確でないことに注意してください。 例えば、いくつかの言語がキャラクタの特定の組み合わせが現れるかもしれないオーダーに制限を課します。 言語に有効で、したがってこの仕様で受入れられたキャラクターは言語でまだ有効な単語かストリングさえ形成していないかもしれません。
(c) When an IDL is associated with a language, it may have Character Variants that depend on that language associated with it in addition to any Preferred Variants. These variants are potential sources of confusion with the Code Points in the original label string. Consequently, the labels generated from them should be unavailable to registrants of other names, words, or phrases.
(c) IDLが言語に関連しているとき、それはどんなPreferred Variantsに加えてそれに関連しているその言語によるキャラクターVariantsを持っているかもしれません。 これらの異形はオリジナルのラベルストリングのCode Pointsへの混乱の可能な源です。 その結果、それらから発生するラベルは他の名前、単語、または句の記入者を入手できないはずです。
During registration, all labels generated from the Character
Variants for the associated language(s) of the IDL should be
reserved.
登録の間、IDLの関連言語のためにキャラクターVariantsから発生するすべてのラベルが予約されるべきです。
IDL reservations of the type described here normally do not appear in the distributed DNS zone file. In other words, these reserved IDLs may not resolve. Domain name holders could request that these reserved IDLs be placed in the zone file and made active and resolvable.
通常、ここで説明されたタイプのIDLの予約は分配されたDNSゾーンファイルに現れません。 言い換えれば、予約されたIDLsが決議しないかもしれないこれら。 ドメイン名所有者はこれらの予約されたIDLsをゾーンファイルに置いて、アクティブで溶解性にするよう要求できました。
Zones will need to establish local policies about how they are to be
made active. Specifically, many zones, especially at the top level,
have prohibited or restricted the use of "CNAME"s DNS aliases,
especially CNAMEs that point to nameserver delegation records (NS
records). And long-term use of long-term aliases for domain
hierarchies, rather than single names ("DNAME records") are
considered problematic because of the recursion they can introduce
into DNS lookups.
ゾーンは、どうそれらをアクティブにすることになっているかに関するローカルの方針を確立する必要があるでしょう。 多くのゾーンが特にトップレベルで使用を明確に、禁止するか、または制限した、「CNAME、「s DNS別名(特にネームサーバ代表団記録(ナノ秒は記録する)を示すCNAMEs)」 そして、ただ一つの名前よりむしろドメイン階層構造のための長期の別名の長期の使用はそれらがDNSルックアップに取り入れることができる再帰のために問題が多いと考えられます(「DNAME記録」)。
(d) When an IDL is a "name", "word", or "phrase", it will have Character Variants depending on the associated language. Furthermore, one or more of those Character Variants will be used more often than others for linguistic, political, or other reasons.
(d) IDLが「名前」、「単語」、または「句」であるときに、それで、キャラクターVariantsは関連言語によるでしょう。 その上、それらのキャラクターVariantsの1つ以上は言語学の、または、政治上の、または、他の理由による他のものよりしばしば使用されるでしょう。
These more commonly used variants are distinguished from ordinary Character Variants and are known as Preferred Variant(s) for the particular language.
これらの一般的により使用された異形は、普通のキャラクターVariantsと区別されて、特定の言語のためのPreferred Variant(s)として知られています。
Konishi, et al. Informational [Page 11] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[11ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
To increase the likelihood of correct and predictable resolution
of the IDN by end users, all labels generated from the Preferred
Variants for the associated language(s) should be resolvable.
エンドユーザによるIDNの正しくて予測できる解決の可能性を広げるために、関連言語のためにPreferred Variantsから発生するすべてのラベルが溶解性であるべきです。
In other words, the Preferred Variant Labels should appear in the distributed DNS zone file.
言い換えれば、Preferred Variant Labelsは分配されたDNSゾーンファイルに現れるはずです。
(e) IDLs associated with one or more languages may have a large number of Character Variant Labels or Preferred Variant Labels. Some of these labels may include combinations of characters that are meaningless or invalid linguistically. It may therefore be appropriate for a zone to adopt procedures that include only linguistically acceptable labels in the IDL Package.
(e) 1つ以上の言語に関連しているIDLsには、多くのキャラクターVariant LabelsかPreferred Variant Labelsがあるかもしれません。 これらのいくつかのラベルが言語学的に無意味であるか、または無効のキャラクタの組み合わせを含むかもしれません。 したがって、ゾーンがIDLパッケージに言語学的に許容できるラベルだけを含んでいる手順を取り入れるのは、適切であるかもしれません。
A zone administrator may impose additional rules and other
processing activities to limit the number of Character Variant
Labels or Preferred Variant Labels that are actually reserved or
registered.
ゾーンの管理者は、実際に予約されるか、または登録されるキャラクターVariant LabelsかPreferred Variant Labelsの数を制限するために付則と他の処理活動を課すかもしれません。
These additional rules and other processing activities are based on policies and/or procedures imposed on a per-zone basis and therefore are not within the scope of this document. Such policies or procedures might be used, for example, to restrict the number of Preferred Variant Labels actually reserved or to prevent certain words from being registered at all.
これらの付則と他の処理活動は、1ゾーンあたり1つの基礎に課された方針、そして/または、手順に基づいていて、したがって、このドキュメントの範囲の中にありません。 例えば、そのような方針か手順が、実際に予約されたPreferred Variant Labelsの数を制限するか、またはある単語が全く登録されるのを防ぐのに用いられるかもしれません。
(f) There are some Character Variant Labels and Preferred Variant Labels that are associated with each IDL. These labels are considered "equivalent" to each another. To avoid confusion, they all should be assigned to a single domain name holder.
(f) 各IDLに関連しているいくつかのキャラクターVariant LabelsとPreferred Variant Labelsがあります。 これらのラベルはそれぞれへの別「同等物」であると考えられます。 混乱を避けるために、それらは皆、単一領域名前所有者に割り当てられるべきです。
The IDL and its variant labels should be grouped together into a
single atomic unit, known in this document as an "IDL Package".
IDLとその異形ラベルは本書では「IDLパッケージ」として知られている単一の原子力単位に一緒に分類されるべきです。
The IDL Package is created upon registration and is atomic: Transfer and deletion of an IDL is performed on the IDL Package as a whole. That is, an IDL within the IDL Package may not be transferred or deleted individually; any re-registration, transfers, or other actions that impact the IDL should also affect the other variants.
IDLパッケージは、登録のときに作成されて、原子です: IDLの転送と削除は全体でIDLパッケージに実行されます。 個別にすなわち、IDLパッケージの中のIDLを移しませんし、また削除しないかもしれません。 IDLに影響を与える再登録、転送、または他の動作がそうするべきであるいずれも他の異形に影響します。
The name-conflict resolution policy associated with this zone could result in a conflict with the principle of IDL Package atomicity. In such a case, the policy must be defined to make the precedence clear.
このゾーンに関連している名前紛争解決方針はIDLパッケージ最小単位の原則との闘争をもたらすかもしれません。 このような場合には、先行を明らかにするために方針を定義しなければなりません。
Konishi, et al. Informational [Page 12] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[12ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
3.2. Registration of IDL
3.2. IDLの登録
To conform to the principles described in 3.1, this document introduces two concepts: the Language Variant Table and the IDL Package. These are described in the next two subsections, followed by a description of the algorithm that is used to interpret the table and generate variant labels.
3.1で説明された原則に従うために、このドキュメントは2つの概念を紹介します: 言語異形テーブルとIDLパッケージ。 これらは、次の2つの小区分で説明されて、テーブルを解釈するのに使用されるアルゴリズムの記述で続いて、異形ラベルを発生させます。
3.2.1. Using the Language Variant Table
3.2.1. 言語異形テーブルを使用します。
For each zone that uses a given language, each language should have its own Language Variant Table. The table consists of a header section that identifies references and version information, followed by a section with one row for each Code Point that is valid for the language and three columns.
与えられた言語を使用する各ゾーンに、各言語はそれ自身のLanguage Variant Tableを持つべきです。 テーブルはそれぞれの言語に、有効なCode Pointあたり1つの列と3つのコラムでセクションによって従われた参照とバージョン情報を特定するヘッダー部分から成ります。
(1) The first column contains the subset of Unicode characters
that is valid to be registered ("Valid Code Point"). This is
used to verify the IDL to be registered (see 3.1b). As in the
registration procedure described later, this column is used as
an index to examine characters that appear in a proposed IDL
to be processed. The collection of Valid Code Points in the
table for a particular language can be thought of as defining
the script for that language, although the normal definition
of a script would not include, for example, ASCII characters
with CJK ones.
(1) 最初のコラムはユニコード文字の登録されているために有効な部分集合(「有効なコード・ポイント」)を含んでいます。 これは、登録されるためにIDLについて確かめるのに使用されます(3.1bを見てください)。 後で説明された登録手順のように、このコラムは、処理されるのに提案されたIDLに現れるキャラクタを調べるインデックスとして使用されます。 その言語のためにスクリプトを定義すると特定の言語のためのテーブルでのValid Code Pointsの収集を考えることができます、スクリプトの通常の定義はCJKもので例えばASCII文字を含んでいないでしょうが。
(2) The second column contains the Preferred Variant(s) of the
corresponding Unicode character in column one ("Valid Code
Point"). These variant characters are used to generate the
Preferred Variant Labels for the IDL. Those labels should be
resolvable (see 3.1d). Under normal circumstances, all of
those Preferred Variant Labels will be activated in the
relevant zone file so that they will resolve when the DNS is
queried for them.
(2) 第2コラムはコラム1(「有効なコード・ポイント」)に対応するユニコード文字のPreferred Variant(s)を含んでいます。 これらの異形キャラクタは、IDLのためにPreferred Variant Labelsを発生させるのに使用されます。 それらのラベルは溶解性であるべきです(3.1dを見てください)。 通常の状況下で、それらのPreferred Variant Labelsのすべては彼らがいつを決議するように関連ゾーンファイルで動かされて、DNSが彼らのために質問されるということでしょう。
(3) The third column contains the Character Variant(s) for the
corresponding Valid Code Point. These are used to generate
the Character Variant Labels of the IDL, which are then to be
reserved (see 3.1c). Registration, or activation, of labels
generated from Character Variants will normally be a
registrant decision, subject to local policy.
(3) 第3コラムは対応するValid Code PointのためのキャラクターVariant(s)を含んでいます。 これらは、そして、予約されることになっているIDLのキャラクターVariant Labelsを発生させるのに使用されます(3.1cを見てください)。 通常、キャラクターVariantsから発生するラベルの登録、または起動がローカルの方針を条件として記入者決定になるでしょう。
Each entry in a column consists of one or more Code Points, expressed as a numeric character number in the Unicode table and optionally followed by a parenthetical reference. The first column, or Valid Code Point, may have only one Code Point specified in a given row. The other columns may have more than one.
コラムにおける各エントリーは挿入句の参照で数字番号がユニコードテーブルに任意に従ったので急送された1Code Pointsから成ります。 最初のコラム、またはValid Code Pointが与えられた列で1Code Pointだけを指定させるかもしれません。 他のコラムには、1つ以上があるかもしれません。
Konishi, et al. Informational [Page 13] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[13ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
Any row may be terminated with an optional comment, starting with "#".
どんな列も任意のコメントで終えられて、「#」から始めるかもしれません。
The formal syntax of the table and more-precise definitions of some of its organization appear in Section 5.
テーブルの正式な構文と何らかの組織の、より正確な定義はセクション5に現れます。
The Language Variant Table should be provided by a relevant group, organization, or body. However, the question of who is relevant or has the authority to create this table and the rules that define it is beyond the scope of this document.
関連グループ、組織、またはボディーはLanguage Variant Tableを提供するべきです。 しかしながら、だれに、関連しているか、またはこのテーブルを作成する権威とそれを定義する規則があるかに関する質問はこのドキュメントの範囲を超えています。
3.2.2. IDL Package
3.2.2. IDLパッケージ
The IDL Package is created on successful registration and consists of:
IDLパッケージは、うまくいっている登録のときに作成されて、以下から成ります。
(1) the IDL registered
(1) IDLは登録しました。
(2) the language(s) associated with the IDL
(2) IDLに関連している言語
(3) the version of the associated character variant table
(3) 関連キャラクタ異形テーブルのバージョン
(4) the reserved IDLs
(4) 予約されたIDLs
(5) active IDLs, that is, "Zone Variant Labels" that are to appear
in the DNS zone file
すなわち、(5)のアクティブなIDLs、DNSゾーンファイルに現れることになっている「ゾーン異形ラベル」
3.2.3. Procedure for Registering IDLs
3.2.3. IDLsを登録するための手順
An explanation follows each step.
説明は各方法に従います。
Step 1. IN <= IDL to be registered and
{L} <= Set of languages associated with IN
1を踏んでください。 IN<は登録されるためにIDLと等しいです、そして、L<はINに関連している言語のセットと等しいです。
Start the process with the label string (prospective IDL) to be registered and the associated language(s) as input.
入力されるように登録されるべきラベルストリング(将来のIDL)と関連言語から過程を始めてください。
Step 2. Generate the Nameprep-processed version of the IN,
applying all mappings and canonicalization required by
IDNA.
2を踏んでください。 すべてのマッピングを適用して、INのNameprepによって処理されたバージョンを発生させてください。そうすれば、canonicalizationがIDNAが必要です。
The prospective IDL is processed by using Nameprep to apply the normalizations and exclusions globally required to use IDNA. If the Nameprep processing fails, then the IDL is invalid and the registration process must stop.
将来のIDLは正常化を適用するのにNameprepを使用することによって、処理されます、そして、除外がIDNAを使用するのがグローバルに必要です。 Nameprep処理が失敗するなら、IDLは無効です、そして、登録手続は止まらなければなりません。
Konishi, et al. Informational [Page 14] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[14ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
Step 2.1. NP(IN) <= Nameprep processed IN
Step 2.2. Check availability of NP(IN). If not available, route to
conflict policy.
2.1を踏んでください。 NP(IN)<=NameprepはIN Step2.2を処理しました。 NP(IN)の有用性をチェックしてください。 利用可能でないなら、闘争方針にルートです。
The Nameprep-processed IDL is then checked against the contents of the zone file and previously created IDL Packages. If it is already registered or reserved, then a conflict exists that must be resolved by applying whatever policy is applicable for the zone. For example, if FCFS is used, the registration process terminates unless the conflict resolution policy provides another alternative.
Nameprepによって処理されたIDLは次に、ゾーンファイルのコンテンツに対してチェックされた、以前に作成されたIDLパッケージです。 それが既に登録されるか、または予約されるなら、どんなゾーンに、適切な方針も適用することによって解決しなければならない闘争は存在しています。 例えば、FCFSが使用されていて、紛争解決方針が別の代替手段を提供しない場合、登録手続は終わります。
Step 3. Process each language.
For each language (AL) in {L}
3を踏んでください。 各言語を処理してください。 中の各言語(AL)のためにL
Step 3 goes through all languages associated with the proposed IDL and checks each character (after Nameprep has been applied) for validity in each of them. It then applies the Preferred Variants (column 2 values) and the Character Variants (column 3 values) to generate candidate labels.
ステップ3は、提案されたIDLに関連しているすべての言語に直面して、それぞれのそれらの正当性がないかどうか各キャラクタ(Nameprepが適用された後に)をチェックします。 そして、それは、候補ラベルを発生させるように、Preferred Variants(コラム2値)とキャラクターVariants(コラム3値)を適用します。
Step 3.1. Check validity of NP(IN) in AL. If failed, stop
processing.
3.1を踏んでください。 ALのNP(IN)の正当性をチェックしてください。 失敗されるなら、処理するのを止めてください。
In step 3.1, IDL validation is done by checking that every Code Point in the Nameprep-processed IDL is a Code Point allowed by the "Valid Code Point" column of the Character Variant Table for the language. This is then repeated for any other languages (and hence, Language Variant Tables) specified in the registration. If one or more Code Points are not valid, the registration process terminates.
ステップ3.1では、Nameprepによって処理されたIDLのあらゆるCode PointがキャラクターVariant Tableに関する「有効なコード・ポイント」コラムによって許容されたCode Pointであることをチェックすることによって、言語のためにIDL合法化をします。 そして、これは登録で指定されたいかなる他の言語(そして、したがって、Language Variant Tables)のためにも繰り返されます。 1Code Pointsが有効でないなら、登録手続は終わります。
Step 3.2. PV(IN,AL) <= Set of available Nameprep-processed Preferred
Variants of NP(IN) in AL
3.2を踏んでください。 =が設定したALのNP(IN)の利用可能なNameprepによって処理されたPreferred VariantsのPV(IN(AL))<。
Step 3.2 generates the list of Preferred Variant Labels of the IDL by doing a combination (see Step 3.2A below) of all possible variants listed in the "Preferred Variant(s)" column for each Code Point in the Nameprep-processed IDL. The generated Preferred Variant Labels must be processed through Nameprep. If the Nameprep processing fails for any Preferred Variant Label (this is unlikely to occur if the Preferred Variants are processed through Nameprep before being placed in the table), then that variant label will be removed from the list. The remaining Preferred Variant Labels in the list are then checked to see whether they are already registered or reserved. If any are registered or reserved, then the conflict resolution policy will apply. In general, this will not prevent the originally requested IDL from being registered unless the policy prevents such registration. For example, if FCFS is applied, then the conflicting variants will be removed from the list, but the originally requested
ステップ3.2は、Nameprepによって処理されたIDLの各Code Pointのための「都合のよい異形」コラムに記載されたすべての可能な異形の組み合わせ(以下のStep 3.2Aを見る)をすることによって、IDLのPreferred Variant Labelsのリストを発生させます。 Nameprepを通して発生しているPreferred Variant Labelsを処理しなければなりません。 Nameprep処理がどんなPreferred Variant Labelのためにも失敗すると(テーブルに置かれる前にPreferred VariantsがNameprepを通して処理されるなら、これは起こりそうにはありません)、リストからその異形ラベルを取り除くでしょう。 そして、リストの残っているPreferred Variant Labelsは、彼らが既に登録されるか、または予約されるかを確認するためにチェックされます。 いずれか登録されるか、または予約されると、紛争解決方針は適用されるでしょう。 一般に、これは、方針がそのような登録を防がない場合元々要求されたIDLが登録されるのを防がないでしょう。 例えば、FCFSが適用していると、しかし、元々リスト、要求されるのから闘争している異形を取り除くでしょう。
Konishi, et al. Informational [Page 15] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[15ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
IDL and any remaining variants will be registered (see steps 5 and 8 below).
IDLとどんな残っている異形も登録されるでしょう(下でのステップ5と8を見てください)。
Step 3.2A Generating variant labels from Variant Code Points.
Variant Code Pointsから3.2A Generating異形ラベルを踏んでください。
Steps 3.2 and 3.3 require that the Preferred Variants and Character Variants be combined with the original IDL to form sets of variant labels. Conceptually, one starts with the original, Nameprep- processed, IDL and examines each of its characters in turn. If a character is encountered for which there is a corresponding Preferred Variant or Character Variant, a new variant label is produced with the Variant Code Point substituted for the original one. If variant labels already exist as the result of the processing of characters that appeared earlier in the original IDL, then the substitutions are made in them as well, resulting in additional generated variant labels. This operation is repeated separately for the Preferred Variants (in Step 3.2) and Character Variants (in Step 3.3). Of course, equivalent results could be achieved by processing the original IDL's characters in order, building the Preferred Variant Label set and Character Variant Label set in parallel.
ステップ3.2と3.3は、Preferred VariantsとキャラクターVariantsが異形ラベルのセットを形成するためにオリジナルのIDLに結合されるのを必要とします。 概念的に、1つは、順番にオリジナル、処理されたNameprep、IDLから始まって、キャラクタ各人を調べます。 対応するPreferred VariantかキャラクターVariantがあるキャラクタが遭遇するなら、新しい変種ラベルはオリジナルのものにVariant Code Pointを代入している状態で作り出されます。 異形ラベルが、より早くオリジナルのIDLに現れたキャラクタの処理の結果として既に存在しているなら、それらでまた、代替をします、追加発生している異形ラベルをもたらして。 この操作はPreferred Variants(Step3.2の)とキャラクターVariants(Step3.3の)のために別々に繰り返されます。 もちろん、同等な結果は整然とした状態でオリジナルのIDLのキャラクタを処理することによって、獲得されるかもしれません、Variant Labelが平行に設定するPreferred Variant Labelセットとキャラクターを造って。
This process will sometimes generate a very large number of labels. For example, if only two of the characters in the original IDL are associated with Preferred Variants and if the first of those characters has three Preferred Variants and the second has two, one ends up with 12 variant labels to be placed in the IDL Package and, normally, in the zone file. Repeating the process for Character Variants, if any exist, would further increase the number of labels. And if more than one language is specified for the original IDL, then repetition of the process for additional languages (see step 4, below) might further increase the size of the set.
この過程は非常に多くのラベルを時々発生させるでしょう。 例えば、オリジナルのキャラクタでは、IDLは2だけであるならPreferred Variantsに関連しています、そして、それらのキャラクタの1番目では3Preferred Variantsがあるか、そして、秒には、IDLパッケージと通常ゾーンファイルに置かれるために、12個の異形ラベルに終わる2、1つの端があります。 いずれか存在しているならキャラクターVariantsのために過程を繰り返すと、ラベルの数はさらに増加するでしょう。 そして、1つ以上の言語がオリジナルのIDLに指定されるなら、追加言語(以下でステップ4を見る)のための過程の反復はセットのサイズをさらに増加させるかもしれません。
Konishi, et al. Informational [Page 16] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[16ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
For illustrative purposes, the "combination" process could be achieved by a recursive function similar to the following pseudocode:
説明に役立った目的のために、「組み合わせ」の過程は以下の擬似コードと同様の再帰的関数によって獲得されるかもしれません:
Function Combination(Str)
F <= first codepoint of Str
SStr <= Substring of Str, without the first code point
NSC <= {}
最初に、Str SStr<の機能Combination(Str)F<=codepointは最初のコード・ポイントNSC<=なしでStrに関するサブストリングと等しいです。{}
If SStr is empty then
for each V in (Variants of code point F)
NSC = NSC set-union (the string with the code point V)
End of Loop
Else
SubCom = Combination(SStr)
For each V in (Variants of code point F)
For each SC in SubCom
NSC = NSC set-union (the string with the
first code point V followed by the string SC)
End of Loop
End of Loop
Endif
SStrが空であるなら、(コード・ポイントFの異形)の各Vに関して、NSCはLoop EndifのLoop EndのSubCom NSC=NSC和集合(最初のコード・ポイントVがストリングサウスカロライナによって続かれているストリング)端の各サウスカロライナのために(コード・ポイントFの異形)の各VのためのLoop Else SubComのNSC和集合(コード・ポイントVがあるストリング)端=組み合わせ(SStr)と等しいです。
Return NSC
リターンNSC
Step 3.3. CV(IN,AL) <= Set of available Nameprep-processed Character
Variants of NP(IN) in AL
3.3を踏んでください。 =が設定したALのNP(IN)の利用可能なNameprepによって処理されたキャラクターVariantsのCV(IN(AL))<。
This step generates the list of Character Variant Labels by doing a combination (see Step 3.2A above) of all the possible variants listed in the "Character Variant(s)" column for each Code Point in the Nameprep-processed original IDL. As with the Preferred Variant Labels, the generated Character Variant Labels must be processed by, and acceptable to, Nameprep. If the Nameprep processing fails for a Character Variant Label, then that variant label will be removed from the list. The remaining Character Variant Labels are then checked to be sure they are not registered or reserved. If one or more are, then the conflict resolution policy is applied. As with Preferred Variant Labels, a conflict that is resolved in favor of the earlier registrant does not, in general, prevent the IDL from being registered, nor the remaining variants from being reserved in step 6 below.
このステップは、Nameprepによって処理されたオリジナルのIDLの各Code Pointのための「キャラクター異形」コラムに記載されたすべての可能な異形の組み合わせ(Step 3.2Aが上であることを見る)をすることによって、キャラクターVariant Labelsのリストを発生させます。 Nameprep、Preferred Variant Labelsなら、発生しているキャラクターVariant Labelsに処理されて、許容できなければなりません。 Nameprep処理がキャラクターVariant Labelのために失敗すると、リストからその異形ラベルを取り除くでしょう。 そして、残っているキャラクターVariant Labelsは、彼らが登録もされませんし、予約もされないのを確信しているようにチェックされます。 1つか以上があるなら、紛争解決方針は適用されています。 一般に、Preferred Variant Labelsのように、以前の記入者を支持して解決されている闘争は、登録されるのからのIDL、および残っている異形が下でのステップ6で予約されるのを防ぎません。
Step 3.4. End of Loop
3.4を踏んでください。 輪の端
Konishi, et al. Informational [Page 17] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[17ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
Step 4. Let PVall be the set-union of all PV(IN,AL)
4を踏んでください。 PVallがすべてのPVの和集合であることをさせてください。(IN(AL))
Step 4 generates the Preferred Variants Label for all languages. In this step, and again in step 6 below, the zone administrator may impose additional rules and processing activities to restrict the number of Preferred (tentatively to be reserved and activated) and Character (tentatively to be reserved) Label Variants. These additional rules and processing activities are zone policy specific and therefore are not specified in this document.
ステップ4はすべての言語のためにPreferred Variants Labelを発生させます。 このステップ、および再び下でのステップ6では、ゾーンの管理者は、Preferred(試験的に、予約されて、動かされる)とキャラクター(試験的に予約される)ラベルVariantsの数を制限するために付則と処理活動を課すかもしれません。 これらの付則と処理活動は、ゾーン方針特有であり、したがって、本書では指定されません。
Step 5. {ZV} <= PVall set-union NP(IN)
5を踏んでください。 ZV、PVall和集合<=NP(中)
Step 5 generates the initial Zone Variants. The set includes all Preferred Variants for all languages and the original Nameprep- processed IDL. Unless excluded by further processing, these Zone Variants will be activated. That is, placed into the DNS zone. Note that the "set-union" operation will eliminate any duplicates.
ステップ5は初期のZone Variantsを発生させます。 セットはすべての言語のためのすべてのPreferred VariantsとオリジナルのNameprep処理IDLを含んでいます。 さらなる処理で除かれないと、これらのZone Variantsは動くでしょう。 すなわち、DNSゾーンに置かれます。 「和集合」操作がどんな写しも排除することに注意してください。
Step 6. Let CVall be the set-union of all CV(IN,AL), set-minus
{ZV}
6を踏んでください。 CVallがすべてのCV(IN(AL))、セットマイナスの和集合であることをさせてください。ZV
Step 6 generates the Reserved Label Variants (the Character Variant Label set). These labels are normally reserved but not activated. The set includes all Character Variant Labels for all languages, but not the Zone Variants defined in the previous step. The set-union and set-minus operations eliminate any duplicates.
ステップ6はReserved Label Variantsを発生させます(キャラクターVariant Labelはセットしました)。 これらのラベルは、通常予約されますが、動きません。 セットは前のステップで定義されたZone Variantsではなく、すべての言語のためのすべてのキャラクターVariant Labelsを含んでいます。 和集合とセットマイナス操作はどんな写しも排除します。
Step 7. Create IDL Package for IN using IN, {L}, {ZV} and CVall
7を踏んでください。 IN、L、ZV、およびCVallを使用して、IDLパッケージをINに作成してください。
In Step 7, the "IDL Package" is created using the original IDL, the associated language(s), the Zone Variant Labels, and the Reserved Variant Labels. If zone-specific additional processing or filtering is to be applied to eliminate linguistically inappropriate or other forms, it should be applied before the IDL Package is actually assembled.
Step7では、「IDLパッケージ」は、オリジナルのIDL、関連言語、Zone Variant Labels、およびReserved Variant Labelsを使用することで作成されます。 ゾーン特有の追加処理かフィルタリングが言語学的に不適当であるか他のフォームを排除するために適用されることであるなら、IDLパッケージが実際に組み立てられる前にそれは適用されるべきです。
Step 8. Put {ZV} into zone file
8を踏んでください。 ゾーンファイルにZVを入れてください。
The activated IDLs are converted via ToASCII with UseSTD13ASCIIRules
[IDNA] before being placed into the zone file. This conversion
results in the IDLs being in the actual IDNA ("Punycode") form used
in zone files, while the IDLs have been carried in Unicode form up to
this point. If ToASCII fails for any of the activated IDLs, that IDL
must not be placed into the zone file. If the IDL is a subdomain
name, it will be delegated.
ゾーンファイルの中に置かれる前に活性IDLsはUseSTD13ASCIIRules[IDNA]とToASCIIを通して変換されます。 この変換はゾーンファイルで使用される実際のIDNA("Punycode")フォームにあるIDLsをもたらします、IDLsがユニコードフォームでこの時点までに運ばれましたが。 ToASCIIが活性IDLsのどれかのために失敗するなら、ゾーンファイルの中にそのIDLを置いてはいけません。 IDLがサブドメイン名であるなら、それを代表として派遣するでしょう。
Konishi, et al. Informational [Page 18] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[18ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
3.3. Deletion and Transfer of IDL and IDL Package
3.3. IDLとIDLパッケージの削除と転送
In traditional domain administration, every Domain Name Label is independent of all other Domain Name Labels. Registration, deletion, and transfer of labels is done on a per-label basis. However, with the guidelines discussed here, each IDL is associated with specific languages, with all label variants, both active (zone) and reserved, together in an IDL Package. This quite deliberately prohibits labels that contain sufficient mixtures of characters from different scripts to make them impossible as words in any given language. If a zone chooses to not impose that restriction--that is, to permit labels to be constructed by picking characters from several different languages and scripts--then the guidelines described here would be inappropriate.
伝統的なドメイン管理では、あらゆるDomain Name Labelが他のすべてのDomain Name Labelsから独立しています。 1ラベルあたり1個のベースでラベルの登録、削除、および転送をします。 しかしながら、それぞれのIDLは特定の言語、すべてのラベル異形に関連していて、かつアクティブ(ゾーン)で、かつここでガイドラインについて議論している状態で、予約されています、IDLパッケージでは、一緒にいます。 これは全く故意に異なったスクリプトからのキャラクタのそれらをどんな与えられた言語の単語としても不可能にすることができるくらいの混合物を含むラベルを禁止します。 ゾーンが、すなわち、いくつかの異なった言語とスクリプトからキャラクタを選ぶことによって組み立てられるべき許可証ラベルへのその制限を課さないのを選ぶなら、ここで説明されたガイドラインは不適当でしょう。
As stated earlier, the IDL package should be treated as a single atomic unit and all variants of the IDL should belong to a single domain-name holder. If the local policy related to the handling of disagreements requires a particular IDL to be transferred and deleted independently of the IDL Package, the conflict policy would take precedence. In such an event, the conflict policy should include a transfer or delete procedure that takes the nature of IDL Packages into consideration.
より早く述べられるように、IDLパッケージは単一の原子力単位として扱われるべきです、そして、IDLのすべての異形が独身のドメイン名所有者のものであるべきです。 不一致の取り扱いに関連するローカルの方針が、特定のIDLがIDLパッケージの如何にかかわらず移されて、削除されるのを必要とするなら、闘争方針は優先するでしょう。 そのような出来事では、闘争方針は、転送を含むべきであるか、またはIDLパッケージの自然を考慮に入れる手順を削除するべきです。
When an IDL Package is deleted, all of the Zone and Reserved Label Variants again become available. The deletion of one IDL Package does not change any other IDL Packages.
IDLパッケージが削除されるとき、ZoneとReserved Label Variantsのすべてが再び利用可能になります。 1つのIDLパッケージの削除はいかなる他のIDLパッケージも変えません。
3.4. Activation and Deactivation of IDL variants
3.4. IDL異形の起動とDeactivation
Because there are active (registered) IDLs and inactive (reserved but not registered) IDLs within an IDL package, processes are required to activate or deactivate IDL variants within an IDL Package.
IDLパッケージの中にアクティブな(登録された)IDLsと不活発な(予約されますが、登録されない)IDLsがあるので、過程がIDLパッケージの中でIDL異形を動かすか、または非活性化するのに必要です。
3.4.1. Activation Algorithm
3.4.1. 起動アルゴリズム
Step 1. IN <= IDL to be activated and PA <= IDL Package
1を踏んでください。 IN<は動かされるためにIDLと等しいです、そして、PA<はIDLパッケージと等しいです。
Start with the IDL to be activated and the IDL Package of which it is a member.
動かされるべきIDLとそれがメンバーであるIDLパッケージから始まってください。
Step 2. NP(IN) <= Nameprep processed IN
2を踏んでください。 NP(IN)<=NameprepはINを処理しました。
Process the IDL through Nameprep. This step should never cause a problem, or even a change, since all labels that become part of the IDL Package are processed through Nameprep in Step 3.2 or 3.3 of the Registration procedure (section 3.2.3).
Nameprepを通してIDLを処理してください。 このステップは問題、または変化さえ決して引き起こすべきではありません、IDLパッケージの一部になるすべてのラベルがRegistration手順(セクション3.2.3)のStep3.2か3.3でNameprepを通して処理されるので。
Konishi, et al. Informational [Page 19] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[19ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
Step 3. If NP(IN) not in CVall then stop
3を踏んでください。 次に、NP(IN)がCVallに止まらないなら
Verify that the Nameprep-processed version of the IDL appears as a still-unactivated label in the IDL Package, i.e., in the list of Reserved Label Variants, CVall. It might be a useful "sanity check" to also verify that it does not already appear in the zone file.
IDLのNameprepによって処理されたバージョンがまだ「非-動か」されたラベルとしてIDLパッケージに現れることを確かめてください、すなわち、Reserved Label Variantsのリストで、CVall。 また、それがゾーンファイルに既に現れないことを確かめるのは、役に立つ「健全度チェック」であるかもしれません。
Step 4. CVall <= CVall set-minus NP(IN) and {ZV} <= {ZV} set-union
NP(IN)
4を踏んでください。 CVall<がCVallセットマイナスNP(IN)とZVと等しい、<がZVと組合を設定する状態で等しい、NP(中)
Within the IDL Package, remove the Nameprep-processed version of the IDL from the list of Reserved Label Variants and add it to the list of active (zone) label variants.
IDLパッケージの中では、Reserved Label VariantsのリストからIDLのNameprepによって処理されたバージョンを移してください、そして、アクティブな(ゾーン)ラベル異形のリストにそれを追加してください。
Step 5. Put {ZV} into the zone file
5を踏んでください。 ゾーンファイルにZVを入れてください。
Actually register (activate) the Zone Variant Labels.
実際にZone Variant Labelsを登録してください(動かします)。
3.4.2. Deactivation Algorithm
3.4.2. 非活性化アルゴリズム
Step 1. IN <= IDL to be deactivated and PA <= IDL Package
1を踏んでください。 IN<は非活性化されるためにIDLと等しいです、そして、PA<はIDLパッケージと等しいです。
As with activation, start with the IDL to be deactivated and the IDL Package of which it is a member.
起動のように、非活性化されるべきIDLとそれがメンバーであるIDLパッケージから始まってください。
Step 2. NP(IN) <= Nameprep processed IN
2を踏んでください。 NP(IN)<=NameprepはINを処理しました。
Get the Nameprep-processed version of the name (see discussion in the previous section).
名前のNameprepによって処理されたバージョンを得てください(前項の議論を見てください)。
Step 3. If NP(IN) not in {ZV} then stop
3を踏んでください。 次に、NP(IN)がZVに止まらないなら
Verify that the Nameprep-processed version of the IDL appears as an activated (zone) label variant in the IDL Package. It might be a useful "sanity check" at this point to also verify that it actually appears in the zone file.
IDLのNameprepによって処理されたバージョンが活性(ゾーン)ラベル異形としてIDLパッケージに現れることを確かめてください。 ここにまた、それが実際にゾーンファイルに現れることを確かめるのは、役に立つ「健全度チェック」であるかもしれません。
Step 4. CVall <= CVall set-union NP(IN) and {ZV} <= {ZV} set-minus
NP(IN)
4を踏んでください。 CVall CVall<=和集合のNP(IN)とZV、<がZVとセットされていた状態で等しい、NP(中)
Within the IDL Package, remove the Nameprep-processed version of the IDL from the list of Active (Zone) Label Variants and add it to the list of Reserved (but inactive) Label Variants.
IDLパッケージの中では、Active(ゾーン)ラベルVariantsのリストからIDLのNameprepによって処理されたバージョンを移してください、そして、Reservedの、そして、(不活発)のラベルVariantsのリストにそれを追加してください。
Step 5. Put {ZV} into the zone file
5を踏んでください。 ゾーンファイルにZVを入れてください。
Konishi, et al. Informational [Page 20] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[20ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
3.5. Managing Changes in Language Associations
3.5. 言語協会における変化を管理します。
Since the IDL package is an atomic unit and the associated list of variants must not be changed after creation, this document does not include a mechanism for adding and deleting language associations within the IDL package. Instead, it recommends deleting the IDL package entirely, followed by a registration with the new set of languages. Zone administrators may find it desirable to devise procedures that prevent other parties from capturing the labels in the IDL Package during these operations.
IDLパッケージが原子力ユニットであり、創造の後に異形の関連リストを変えてはいけないので、このドキュメントはIDLパッケージの中に言語協会を加えて、削除するためのメカニズムを含んでいません。 代わりに、それは、新しい言語による登録があとに続いていて、IDLパッケージを完全に削除することを勧めます。 ゾーンの管理者は、相手がこれらの操作の間にIDLパッケージでラベルを捕らえることができない手順について工夫するのが望ましいのがわかるかもしれません。
3.6. Managing Changes to the Language Variant Tables
3.6. 言語異形テーブルへの変化を管理します。
Language Variant Tables are subject to changes over time, and these changes may or may not be backward compatible. It is possible that updated Language Variant Tables may produce a different set of Preferred Variants and Reserved Variants.
言語Variant Tablesは時間がたつにつれて変化を条件としています、そして、これらの変化は後方であるかもしれません。互換性がある。 アップデートされたLanguage Variant TablesがPreferred VariantsとReserved Variantsの異なったセットを生産するのは、可能です。
In order to preserve the atomicity of the IDL Package, when the Language Variant Table is changed, IDL Packages created using the previous version of the Language Variant Table must not be updated or affected.
Language Variant Tableを変えるとき、IDLパッケージの最小単位を保存するために、Language Variant Tableの旧バージョンを使用することで作成されたIDLパッケージは、アップデートしてはいけませんし、また影響を受けてはいけません。
4. Examples of Guideline Use in Zones
4. ゾーンでのガイドライン使用に関する例
To provide a meaningful example, some Language Variant Tables must be defined. Assume, then, for the purpose of giving examples, that the following four Language Variant Tables are defined:
重要な例を提供するために、いくつかのLanguage Variant Tablesを定義しなければなりません。 次に、例を挙げる目的には、以下の4Language Variant Tablesが定義されると仮定してください:
Note: these tables are not a representation of the actual tables, and they do not contain sufficient entries to be used in any actual implementation. IANA maintains a voluntary registry of actual tables [IANA-LVTABLES] which may be consulted for complete examples.
以下に注意してください。 これらのテーブルは実際のテーブルの表現ではありません、そして、それらはどんな実際の実現にも使用できるくらいのエントリーを含んでいません。 IANAは完全な例のために相談されるかもしれない実際のテーブル[IANA-LVTABLES]の自発的の登録を維持します。
a) Language Variant Table for zh-cn and zh-sg
a) zh-cnとzh-sgのための言語Variant Table
Reference 1 CP936 (commonly known as GBK) Reference 2 zVariant, zTradVariant, zSimpVariant in Unihan.txt [UNIHAN] Reference 3 List of Simplified character Table (Simplified column) Reference 4 zSimpVariant in Unihan.txt [UNIHAN] Reference 5 variant that exists in GB2312, common simplified hanzi
参照1CP936(GBKとして一般的に知られている)参照2zVariant、zTradVariant、GB2312、一般的な簡易型のhanziに存在するUnihan.txt[UNIHAN]参照5異形のSimplifiedキャラクタTable(簡易型のコラム)参照4zSimpVariantのUnihan.txt[UNIHAN]参照3ListのzSimpVariant
Version 1 20020701 # July 2002
バージョン1 2002年20020701#7月
56E2(1);56E2(5);5718(2) # sphere, ball, circle; mass, lump 5718(1);56E2(4);56E2(2),56E3(2) # sphere, ball, circle; mass, lump 60F3(1);60F3(5); # think, speculate, plan, consider 654E(1);6559(5);6559(2) # teach
56Eの2(1); 56Eの2(5); 5718(2)#球、ボールは旋回します。 固まり、塊の5718(1); 56Eの2(4); 56Eの2(2)、56Eの3(2)#球、ボールは旋回します。 塊の60F3(1)、ひと固まりになってください; 60F3(5) # 考えてください、そして、推測してください、そして、計画してください、そして、654Eの(1); 6559(5); 6559(2)#が教えられると考えてください。
Konishi, et al. Informational [Page 21] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[21ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
6559(1);6559(5);654E(2) # teach, class 6DF8(1);6E05(5);6E05(2) # clear 6E05(1);6E05(5);6DF8(2) # clear, pure, clean; peaceful 771E(1);771F(5);771F(2) # real, actual, true, genuine 771F(1);771F(5);771E(2) # real, actual, true, genuine 8054(1);8054(3);806F(2) # connect, join; associate, ally 806F(1);8054(3);8054(2),8068(2) # connect, join; associate, ally 96C6(1);96C6(5); # assemble, collect together
6559(1); 6559(5); 654E(2)#は教えられて、6DF8(1); 6Eの05(5); 6Eのクラス05(2)#が明確で、純粋で、清潔な状態で6Eの05(1); 6Eの05(5); 6DF8(2)#をきれいにします。 平和な771Eの(1); 771F(5); 771のF(2)#本当の、そして、実際の本当の、そして、本物の771F(1); 771F(5); 771Eの(2)#の本当の、そして、実際の、そして、本当の、そして、本物の8054(1); 8054(3); 806F(2)#を接続して、接合してください。 交際してください、そして、同盟国806F(1); 8054(3); 8054(2)、8068(2)#を接続して、接合してください。 同盟国96C6(1)、交際してください; 96C6(5) # 集合してください、そして、一緒に集まってください。
b) Language Variant Table for zh-tw
b) zh-twのための言語Variant Table
Reference 1 CP950 (commonly known as BIG5) Reference 2 zVariant, zTradVariant, zSimpVariant in Unihan.txt Reference 3 List of Simplified Character Table (Traditional column) Reference 4 zTradVariant in Unihan.txt
参照1CP950(BIG5として一般的に知られている)参照2zVariant、zTradVariant、Unihan.txtのSimplifiedキャラクターTable(伝統的なコラム)参照4zTradVariantのUnihan.txt Reference3ListのzSimpVariant
Version 1 20020701 # July 2002
バージョン1 2002年20020701#7月
5718(1);5718(4);56E2(2),56E3(2) # sphere, ball, circle; mass, lump 60F3(1);60F3(1); # think, speculate, plan, consider 6559(1);6559(1);654E(2) # teach, class 6E05(1);6E05(1);6DF8(2) # clear, pure, clean; peaceful 771F(1);771F(1);771E(2) # real, actual, true, genuine 806F(1);806F(3);8054(2),8068(2) # connect, join; associate, ally 96C6(1);96C6(1); # assemble, collect together
5718(1); 5718(4); 56Eの2(2)、56Eの3(2)#球、ボールは旋回します。 塊の60F3(1)、ひと固まりになってください; 60F3(1) # 考えてください、そして、推測してください、そして、計画してください、そして、6559(1); 6559(1); 654E(2)#が教えられると考えてください、そして、6Eの05(1); 6Eの05(1); 6DF8(2)#がきれいにする純粋なクラスは掃除されます。 平和な771F(1); 771F(1); 771E(2)の#本当の、そして、実際の本当の、そして、本物の806F(1); 806F(3); 8054(2)、8068(2)#、を接続して、接合してください。 同盟国96C6(1)、交際してください; 96C6(1) # 集合してください、そして、一緒に集まってください。
c) Language Variant Table for ja
c) jaのための言語Variant Table
Reference 1 CP932 (commonly known as Shift-JIS) Reference 2 zVariant in Unihan.txt Reference 3 variant that exists in JIS X0208, commonly used Kanji
Unihan.txt Reference3異形のJIS X0208に存在する参照1CP932(Shift-JISとして一般的に知られている)参照2zVariant、一般的に使用されたKanji
Version 1 20020701 # July 2002
バージョン1 2002年20020701#7月
5718(1);5718(3);56E3(2) # sphere, ball, circle; mass, lump 60F3(1);60F3(3); # think, speculate, plan, consider 654E(1);6559(3);6559(2) # teach 6559(1);6559(3);654E(2) # teach, class 6DF8(1);6E05(3);6E05(2) # clear 6E05(1);6E05(3);6DF8(2) # clear, pure, clean; peaceful 771E(1);771E(1);771F(2) # real, actual, true, genuine 771F(1);771F(1);771E(2) # real, actual, true, genuine 806F(1);806F(1);8068(2) # connect, join; associate, ally 96C6(1);96C6(3); # assemble, collect together
5718(1); 5718(3); 56Eの3(2)#球、ボールは旋回します。 塊の60F3(1)、ひと固まりになってください; 60F3(3) # 考えてください、そして、推測してください、そして、計画してください、そして、明確な6Eの05(1); 6Eの05(3); 6559(2)#が教えることを6559(1); 6559(3); 654Eの(2)#に教える654ユーロ(1)(6559(3))、クラス6DF8(1); 6Eの05(3); 6E05(2)#6DF8(2)#が明確で、純粋で、清潔であると考えてください。 平和な771Eの(1); 771Eの(1); 本当の、そして、実際の本当の、そして、本物の771F(1); 771F(2)#の771F(1)(771E(2)の#本当の、そして、実際の本当の、そして、本物の806F(1); 806F(1))の8068(2)#を接続して、接合してください。 同盟国96C6(1)、交際してください; 96C6(3) # 集合してください、そして、一緒に集まってください。
d) Language Variant Table for ko
d) koのための言語Variant Table
Reference 1 CP949 (commonly known as EUC-KR)
参照1CP949(EUC-KRとして一般的に知られています)
Konishi, et al. Informational [Page 22] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[22ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
Reference 2 zVariant and K-source in Unihan.txt
Unihan.txtの参照2zVariantとKソース
Version 1 20020701 # July 2002
バージョン1 2002年20020701#7月
5718(1);5718(1);56E3(2) # sphere, ball, circle; mass, lump 60F3(1);60F3(1); # think, speculate, plan, consider 654E(1);654E(1);6559(2) # teach 6DF8(1);6DF8(1);6E05(2) # clear 771E(1);771E(1);771F(2) # real, actual, true, genuine 806F(1);806F(1);8068(2) # connect, join; associate, ally 96C6(1);96C6(1); # assemble, collect together
5718(1); 5718(1); 56Eの3(2)#球、ボールは旋回します。 塊の60F3(1)、ひと固まりになってください; 60F3(1) # 考えてください、そして、推測してください、そして、計画してください、そして、6559(2)#が接続することを明確な771Eの(1); 771E(1); 771F(2)#本当の、そして、実際の本当の、そして、本物の806F(1); 806F(1); 6DF8(1); 6DF8(1); 6Eの05(2)#8068(2)#に教える654E(1)(654Eの(1))が接合すると考えてください。 同盟国96C6(1)、交際してください; 96C6(1) # 集合してください、そして、一緒に集まってください。
Example 1: IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
{L} = {zh-cn, zh-sg, zh-tw}
例1: IDLは(U+6 05ユーロのU+771F U+6559)*qing2 zhen1 jiao4*L=と等しいです。zh-cn、zh-sg、zh-tw
NP(IN) = (U+6E05 U+771F U+6559) PV(IN,zh-cn) = (U+6E05 U+771F U+6559) PV(IN,zh-sg) = (U+6E05 U+771F U+6559) PV(IN,zh-tw) = (U+6E05 U+771F U+6559)
Np..等しい(U+6 05ユーロのU+771F U+6559)
{ZV} = {(U+6E05 U+771F U+6559)}
CVall = {(U+6E05 U+771E U+6559),
(U+6E05 U+771E U+654E),
(U+6E05 U+771F U+654E),
(U+6DF8 U+771E U+6559),
(U+6DF8 U+771E U+654E),
(U+6DF8 U+771F U+6559),
(U+6DF8 U+771F U+654E)}
ZVは(U+6 05ユーロのU+771F U+6559)CVall=と等しいです。{(U+6E05 U+771E U+6559), (U+6E05 U+771E U+654E), (U+6E05 U+771F U+654E), (U+6DF8 U+771E U+6559), (U+6DF8 U+771E U+654E), (U+6DF8 U+771F U+6559), (U+6DF8 U+771F U+654E)}
Example 2: IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
{L} = {ja}
例2: IDLは(U+6 05ユーロのU+771F U+6559)*qing2 zhen1 jiao4*L=と等しいです。ja
NP(IN) = (U+6E05 U+771F U+6559)
PV(IN,ja) = (U+6E05 U+771F U+6559)
{ZV} = {(U+6E05 U+771F U+6559)}
Np(IN)=(U+6 05ユーロのU+771F U+6559)PV(jaのIN)は(U+6 05ユーロのU+771F U+6559)ZV=と等しいです。(U+6 05ユーロのU+771F U+6559)
CVall = {(U+6E05 U+771E U+6559),
(U+6E05 U+771E U+654E),
(U+6E05 U+771F U+654E),
(U+6DF8 U+771E U+6559),
(U+6DF8 U+771E U+654E),
(U+6DF8 U+771F U+6559),
(U+6DF8 U+771F U+654E)}
CVall={(U+6E05 U+771E U+6559), (U+6E05 U+771E U+654E), (U+6E05 U+771F U+654E), (U+6DF8 U+771E U+6559), (U+6DF8 U+771E U+654E), (U+6DF8 U+771F U+6559), (U+6DF8 U+771F U+654E)}
Example 3: IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
{L} = {zh-cn, zh-sg, zh-tw, ja, ko}
例3: IDLは(U+6 05ユーロのU+771F U+6559)*qing2 zhen1 jiao4*L=と等しいです。zh-cn、zh-sg、zh-tw、ja、ko
NP(IN) = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
NP(IN)は*qing2 zhen1 jiao4*と等しいです(U+6 05ユーロのU+771F U+6559)。
Konishi, et al. Informational [Page 23] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[23ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
Invalid registration because U+6E05 is invalid in L = ko
05U+6ユーロがLで無効であるので、無効の登録はkoと等しいです。
Example 4: IDL = (U+806F U+60F3 U+96C6 U+5718)
*lian2 xiang3 ji2 tuan2*
{L} = {zh-cn, zh-sg, zh-tw}
例4: IDLは(U+806FのU+60F3U+96C6U+5718)*lian2 xiang3 ji2 tuan2*L=と等しいです。zh-cn、zh-sg、zh-tw
NP(IN) = (U+806F U+60F3 U+96C6 U+5718)
PV(IN,zh-cn) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-sg) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-tw) = (U+806F U+60F3 U+96C6 U+5718)
{ZV} = {(U+8054 U+60F3 U+96C6 U+56E2),
(U+806F U+60F3 U+96C6 U+5718)}
CVall = {(U+8054 U+60F3 U+96C6 U+56E3),
(U+8054 U+60F3 U+96C6 U+5718),
(U+806F U+60F3 U+96C6 U+56E2),
(U+806f U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+56E2),
(U+8068 U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+5718)
NP(IN) = (U+806F U+60F3 U+96C6 U+5718) PV(IN,zh-cn) = (U+8054 U+60F3 U+96C6 U+56E2) PV(IN,zh-sg) = (U+8054 U+60F3 U+96C6 U+56E2) PV(IN,zh-tw) = (U+806F U+60F3 U+96C6 U+5718) {ZV} = {(U+8054 U+60F3 U+96C6 U+56E2), (U+806F U+60F3 U+96C6 U+5718)} CVall = {(U+8054 U+60F3 U+96C6 U+56E3), (U+8054 U+60F3 U+96C6 U+5718), (U+806F U+60F3 U+96C6 U+56E2), (U+806f U+60F3 U+96C6 U+56E3), (U+8068 U+60F3 U+96C6 U+56E2), (U+8068 U+60F3 U+96C6 U+56E3), (U+8068U+60F3U+96C6U+5718)
Example 5: IDL = (U+8054 U+60F3 U+96C6 U+56E2)
*lian2 xiang3 ji2 tuan2*
{L} = {zh-cn, zh-sg}
例5: IDLは(U+8054U+60F3U+96C6U+56E2)*lian2 xiang3 ji2 tuan2*L=と等しいです。zh-cn、zh-sg
NP(IN) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-cn) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-sg) = (U+8054 U+60F3 U+96C6 U+56E2)
{ZV} = {(U+8054 U+60F3 U+96C6 U+56E2)}
CVall = {(U+8054 U+60F3 U+96C6 U+56E3),
(U+8054 U+60F3 U+96C6 U+5718),
(U+806F U+60F3 U+96C6 U+56E2),
(U+806f U+60F3 U+96C6 U+56E3),
(U+806F U+60F3 U+96C6 U+5718),
(U+8068 U+60F3 U+96C6 U+56E2),
(U+8068 U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+5718)}
Np..等しい{(U+8054 U+60F3 U+96C6 U+56E3), (U+8054 U+60F3 U+96C6 U+5718), (U+806F U+60F3 U+96C6 U+56E2), (U+806f U+60F3 U+96C6 U+56E3), (U+806F U+60F3 U+96C6 U+5718), (U+8068 U+60F3 U+96C6 U+56E2), (U+8068 U+60F3 U+96C6 U+56E3), (U+8068 U+60F3 U+96C6 U+5718)}
Example 6: IDL = (U+8054 U+60F3 U+96C6 U+56E2)
*lian2 xiang3 ji2 tuan2*
{L} = {zh-cn, zh-sg, zh-tw}
例6: IDLは(U+8054U+60F3U+96C6U+56E2)*lian2 xiang3 ji2 tuan2*L=と等しいです。zh-cn、zh-sg、zh-tw
NP(IN) = (U+8054 U+60F3 U+96C6 U+56E2) Invalid registration because U+8054 is invalid in L = zh-tw
U+8054がL=zh-twで無効であるので、NP(IN)は無効の登録と等しいです(U+8054U+60F3U+96C6U+56E2)。
Example 7: IDL = (U+806F U+60F3 U+96C6 U+5718)
*lian2 xiang3 ji2 tuan2*
{L} = {ja,ko}
例7: IDLは(U+806FのU+60F3U+96C6U+5718)*lian2 xiang3 ji2 tuan2*L=と等しいです。ja、ko
Konishi, et al. Informational [Page 24] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[24ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
NP(IN) = (U+806F U+60F3 U+96C6 U+5718)
PV(IN,ja) = (U+806F U+60F3 U+96C6 U+5718)
PV(IN,ko) = (U+806F U+60F3 U+96C6 U+5718)
{ZV} = {(U+806F U+60F3 U+96C6 U+5718)}
Np(IN)=(U+806FのU+60F3U+96C6U+5718)PV(jaのIN)=(U+806FのU+60F3U+96C6U+5718)PV(koのIN)は(U+806FのU+60F3U+96C6U+5718)ZV=と等しいです。(U+806FのU+60F3U+96C6U+5718)
CVall = {(U+806F U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+5718),
(U+8068 U+60F3 U+96C6 U+56E3)}
CVall=(60F3U+96C6U+56 3U+806F U+ユーロ)、(U+8068U+60F3U+96C6U+5718)(U+8068U+60F3U+96C6U+56E3)
5. Syntax Description for the Language Variant Table
5. 言語異形テーブルのための構文記述
The formal syntax for the Language Variant Table is as follows, using the IETF "ABNF" metalanguage [ABNF]. Some comments on this syntax appear immediately after it.
IETF"ABNF"メタ言語[ABNF]を使用して、Language Variant Tableに、正式な構文は以下の通りです。 この構文のいくつかのコメントがそれ直後現れます。
5.1. ABNF Syntax
5.1. ABNF構文
LanguageVariantTable = 1*ReferenceLine VersionLine 1*EntryLine ReferenceLine = "Reference" SP RefNo SP RefDesciption [ Comment ] CRLF RefNo = 1*DIGIT RefDesciption = *[VCHAR] VersionLine = "Version" SP VersionNo SP VersionDate [ Comment ] CRLF VersionNo = 1*DIGIT VersionDate = YYYYMMDD EntryLine = VariantEntry/Comment CRLF
LanguageVariantTable=1*ReferenceLine VersionLine1*EntryLine ReferenceLine=「参照」SP RefNo SP RefDesciption[コメント]CRLF RefNo=1*ケタRefDesciption=*[VCHAR]VersionLine=「バージョン」SP VersionNo SP VersionDate[コメント]CRLF VersionNoは1*ケタVersionDate=YYYYMMDD EntryLine=VariantEntry/コメントCRLFと等しいです。
VariantEntry = ValidCodePoint ";"
PreferredVariant ";" CharacterVariant [ Comment ]
ValidCodePoint = CodePoint
RefList = RefNo 0*( "," RefNo )
PreferredVariant = CodePointSet 0*( "," CodePointSet )
CharacterVariant = CodePointSet 0*( "," CodePointSet )
CodePointSet = CodePoint 0*( SP CodePoint )
CodePoint = 4*8DIGIT [ "(" Reflist ")" ]
Comment = "#" *VCHAR
「VariantEntryはValidCodePointと等しい」;、」 "PreferredVariant";、」 CharacterVariant[コメント]ValidCodePoint=CodePoint RefListがRefNo0*と等しい、(「」、RefNo) PreferredVariantがCodePointSet0*と等しい、(「」、CodePointSet) CharacterVariantがCodePointSet0*と等しい、(「」、CodePoint0*(SP CodePoint)CodePointSet) CodePointSet=CodePointは4*8DIGIT[「("Reflist")」]コメント=「#」*VCHARと等しいです。
YYYYMMDD is an integer, in alphabetic form, representing a date, where YYYY is the 4-digit year, MM is the 2-digit month, and DD is the 2-digit day.
YYYYMMDDは整数です、アルファベットフォームで、日付(YYYYは4ケタの年です、そして、MMは2ケタの月です、そして、DDは2ケタの日である)を表して。
5.2. Comments and Explanation of Syntax
5.2. 構文に関するコメントと説明
Any lines starting with, or portions of lines after, the hash
symbol("#") are treated as comments. Comments have no significance
in the processing of the tables; nor are there any syntax
requirements between the hash symbol and the end of the line. Blank
lines in the tables are ignored completely.
いずれも、後の線を立ち並んでいるか、または分配して、細切れ肉料理シンボル(「#」)はコメントとして扱われます。 コメントには、テーブルの処理における意味が全くありません。 また、細切れ肉料理シンボルと行の終わりの間には、どんな構文要件もありません。 テーブルの空白行は完全に無視されます。
Konishi, et al. Informational [Page 25] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[25ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
Every language should have its own Language Variant Table provided by a relevant group, organization, or other body. That table will normally be based on some established standard or standards. The group that defines a Language Variant Table should document references to the appropriate standards at the beginning of the table, tagged with the word "Reference" followed by an integer (the reference number) followed by the description of the reference. For example:
あらゆる言語で、関連グループ、組織、または他のボディーはそれ自身のLanguage Variant Tableを提供するべきです。 通常、そのテーブルはいくつかの確立した規格か規格に基づくでしょう。 Language Variant Tableを定義するグループは参照の記述があとに続いた整数(参照番号)が「参照」という言葉のあとに続いていてタグ付けをされたテーブルの始めにおける適切な規格の参照を記録するべきです。 例えば:
Reference 1 CP936 (commonly known as GBK) Reference 2 zVariant, zTradVariant, zSimpVariant in Unihan.txt Reference 3 List of Simplified Character Table (Simplified column) Reference 4 zSimpVariant in Unihan.txt Reference 5 Variant that exists in GB2312, common simplified Hanzi
参照1CP936(GBKとして一般的に知られている)参照2zVariant、zTradVariant、GB2312に存在するUnihan.txt Reference5Variant、一般的な簡易型のHanziのSimplifiedキャラクターTable(簡易型のコラム)参照4zSimpVariantのUnihan.txt Reference3ListのzSimpVariant
Each Language Variant Table must have a version number and its release date. This is tagged with the word "Version" followed by an integer then followed by the date in the format YYYYMMDD, where YYYY is the 4-digit year, MM is the 2-digit month, and DD is the 2-digit day of the publication date of the table.
各Language Variant Tableには、バージョン番号とその公開日がなければなりません。 これは形式YYYYMMDDで整数がその時あとに続いた「バージョン」が日付までに続いたという単語でタグ付けをされます。そこでは、YYYYが4ケタの年であり、MMが2ケタの月であり、DDはテーブルの公表日付の2ケタの日です。
Version 1 20020701 # July 2002 Version 1
バージョン1 2002年20020701#7月のバージョン1
The table has three columns, separated by semicolons: "Valid Code Point"; "Preferred Variant(s)"; and "Character Variant(s)".
テーブルには、セミコロンによって切り離された3つのコラムがあります: 「有効なコード・ポイント」。 「都合のよい異形(s)」。 そして、「キャラクター異形。」
The "Valid Code Point" is the subset of Unicode characters that are valid to be registered.
「有効なコード・ポイント」は登録されているために有効なユニコード文字の部分集合です。
There can be more than one Preferred Variant; hence there could be multiple entries in the "Preferred Variant(s)" column. If the "Preferred Variant(s)" column is empty, then there is no corresponding Preferred Variant; in other words, the Preferred Variant is null, there is no corresponding preferred variant codepoint, and no processing to add labels for preferred variants occurs." Unless local policy dictates otherwise, the procedures above will result in only those labels that reflect the valid code point being activated (registered) into the zone file.
1Preferred Variantがあることができます。 したがって、「都合のよい異形」コラムには多回入国があるかもしれません。 「都合のよい異形」コラムが空であるなら、どんな対応するPreferred Variantもありません。 「言い換えれば、Preferred Variantはヌルです、そして、対応する都合のよい異形がないcodepointがあります、そして、都合のよい異形のためにラベルを加えるために処理するのは起こりません。」 ローカルの方針が別の方法で命令しないと、上の手順はゾーンファイルの中に動かされる(登録されます)有効なコード・ポイントを反映するそれらのラベルだけをもたらすでしょう。
The "Character Variant(s)" column contains all Character Variants of the Code Point. Since the Code Point is always a variant of itself, to avoid redundancy, the Code Point is assumed to be part of the "Character Variant(s)" and need not be repeated in the "Character Variant(s)" column.
「キャラクター異形」コラムはCode PointのすべてのキャラクターVariantsを含んでいます。 いつもCode Pointが冗長を避けるためにはそれ自体の異形であるので、Code Pointは「キャラクター異形」の一部であると思われて、「キャラクター異形」コラムで繰り返される必要はありません。
If the variant in the "Preferred Variant(s)" or the "Character Variant(s)" column is composed of a sequence of Code Points, then sequence of Code Points is listed separated by a space.
「都合のよい異形」か「キャラクター異形」コラムの異形がCode Pointsの系列で構成されるなら、Code Pointsの系列はスペースによって切り離された状態で記載されます。
Konishi, et al. Informational [Page 26] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[26ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
If there are multiple variants in the "Preferred Variant(s)" or the "Character Variant(s)" column, then each variant is separated by a comma.
「都合のよい異形」か「キャラクター異形」コラムに複数の異形があれば、各異形はコンマによって切り離されます。
Any Code Point listed in the "Preferred Variant(s)" column must be allowed by the rules for the relevant language to be registered. However, this is not a requirement for the entries in the "Character Variant(s)" column; it is possible that some of those entries may not be allowed to be registered.
関連言語は「都合のよい異形」コラムに記載されたどんなCode Pointにも規則で登録させていなければなりません。 しかしながら、これは「キャラクター異形」コラムにおけるエントリーのための要件ではありません。 それらのエントリーのいくつかが登録できないのは、可能です。
Every Code Point in the table should have a corresponding reference number (associated with the references) specified to justify the entry. The reference number is placed in parentheses after the Code Point. If there is more than one reference, then the numbers are placed within a single set of parentheses and separated by commas.
テーブルのあらゆるCode Pointが、エントリーを正当化するために、対応する参照番号(参照に関連している)を指定させるはずです。 参照番号はCode Pointの後の括弧に置かれます。 1つ以上の参照箇所があれば、数は、1セットの括弧の中に置かれて、コンマによって切り離されます。
6. Security Considerations
6. セキュリティ問題
As discussed in the Introduction, substantially-unrestricted use of international (non-ASCII) characters in domain name labels may cause user confusion and invite various types of attacks. In particular, in the case of CJK languages, an attacker has an opportunity to divert or confuse users as a result of different characters (or, more specifically, assigned code points) with identical or similar semantics. These Guidelines provide a partial remedy for those risks by supplying a framework for prohibiting inappropriate characters from being registered at all and for permitting "variant" characters to be grouped together and reserved, so that they can only be registered in the DNS by the same owner. However, the system it suggests is no better or worse than the per-zone and per-language tables whose format and use this document specifies. Specific tables, and any additional local processing, will reflect per-zone decisions about the balance between risk and flexibility of registrations. And, of course, errors in construction of those tables may significantly reduce the quality of protection provided.
Introductionで議論するように、ドメイン名ラベルにおける国際的な(非ASCIIの)キャラクタの実質的に無制限な使用は、ユーザに混乱を引き起こして、様々なタイプの攻撃を招待するかもしれません。 CJK言語の場合では、特に、攻撃者は異なったキャラクタの結果、同じであるか同様の意味論にユーザを紛らすか、または混乱させる(または、より明確に、コード・ポイントを割り当てます)機会を持っています。 これらのGuidelinesは不適当なキャラクタが全く示されるのを禁止して、「異形」キャラクタが一緒に分類されて、予約されることを許可するのに枠組みを供給することによって、それらのリスクのための部分的な療法を提供します、同じ所有者がDNSに彼らを登録できるだけであるように。 しかしながら、それが示すシステムは、このドキュメントが形式と使用を指定するゾーンと1言語あたりのテーブルよりさらに良くないか、または悪いです。 特定のテーブル、およびどんな追加ローカル処理も登録証明書のリスクと柔軟性の間のバランスに関する1ゾーンあたりの決定を反映するでしょう。 もちろん、そして、それらのテーブルの構造における誤りは提供された保護の品質をかなり減少させるかもしれません。
7. Index to Terminology
7. 用語に索引をつけてください。
As a convenience to the reader, this section lists all of the special terminology used in this document, with a pointer to the section in which it is defined.
読者への便利として、このセクションは本書では使用される特別な用語のすべてを記載します、それが定義されるセクションへのポインタで。
Activated Label 2.1.17
Activation 2.1.4
Active Label 2.1.17
Character Variant 2.1.14
Character Variant Label 2.1.16
CJK Characters 2.1.9
活性ラベル2.1.17の起動2.1.4の活性ラベル2.1.17キャラクター異形2.1.14キャラクター異形ラベル2.1.16のCJKキャラクター2.1.9
Konishi, et al. Informational [Page 27] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[27ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
Code point 2.1.7
Code Point Variant 2.1.14
FQDN 2.1.3
Hostname 2.1.1
IDL 2.1.2
IDL Package 2.1.18
IDN 2.1.1
Internationalized Domain Label 2.1.2
ISO/IEC 10646 2.1.6
Label String 2.1.10
Language name codes 2.1.5
Language Variant Table 2.1.11
LDH Subset 2.1.1
Preferred Code Point 2.1.13
Preferred Variant 2.1.13
Preferred Variant Label 2.1.15
Registration 2.1.4
Reserved 2.1.18
RFC3066 2.1.5
Table 2.1.11
UCS 2.1.6
Unicode Character 2.1.7
Unicode String 2.1.8
Valid Code Point 2.1.12
Variant Table 2.1.11
Zone Variant 2.1.17
コード・ポイント2.1.7Code Point Variant2.1.14FQDN2.1.3Hostname2.1.1IDL2.1.2IDLパッケージ2.1.18IDN2.1.1Internationalized Domain Label2.1.2ISO/IEC10646 2.1.6Label String2.1.10Languageは2.1.5Language Variant Table2.1.11LDH Subset2.1とコードを命名します; 1 都合のよいコード・ポイント2.1.13の都合のよい異形2.1.13は異形ラベル2.1.15の登録2.1.4の予約された2.1.18RFC3066 2.1.5テーブル2.1.11UCS2.1.6ユニコードキャラクター2.1.7ユニコードストリング2.1.8有効なコード・ポイント2.1.12異形テーブル2.1.11ゾーン異形2.1.17を好みました。
8. Acknowledgments
8. 承認
The authors gratefully acknowledge the contributions of:
作者は感謝して以下の貢献を承諾します。
- V. CHEN, N. HSU, H. HOTTA, S. TASHIRO, Y. YONEYA, and other Joint
Engineering Team members at the JET meeting in Bangkok, Thailand.
- V.チェン、N.シュー、H.掘田、S.田代、Y. YONEYA、およびバンコク(タイ)でのJETミーティングにおける他のJoint Engineering Teamメンバー。
- Yves Arrouye, an observer at the JET meeting in Bangkok, for his
contribution on the IDL Package.
- イヴArrouye、IDLパッケージにおける彼の貢献のためのバンコクでのJETミーティングにおけるオブザーバ。
- Those who commented on, and made suggestions about, earlier
versions, including Harald ALVESTRAND, Erin CHEN, Patrik
FALTSTROM, Paul HOFFMAN, Soobok LEE, LEE Xiaodong, MAO Wei, Erik
NORDMARK, and L.M. TSENG.
- ハラルドALVESTRAND、アイルランドのチェン、パトリクFALTSTROM、ポール・ホフマン、Soobok LEE、LEEシャオドン、MAOウェイ、エリックNORDMARK、およびL. M. TSENGを含む以前のバージョンに関してコメントして、提案をした人。
Konishi, et al. Informational [Page 28] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[28ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[ABNF] Crocker, D. and P. Overell, Eds., "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, November
1997.
[ABNF] クロッカーとD.とP.Overell、Eds、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[STD13] Mockapetris, P., "Domain names concepts and
facilities" STD 13, RFC 1034, November 1987.
Mockapetris, P., "Domain names implementation and
specification", STD 13, RFC 1035, November 1987.
[STD13]Mockapetris、P.、「ドメイン名概念と施設」STD13、RFC1034、1987年11月。 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月。
[IDNA] Faltstrom, P., Hoffman, P. and A. M. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[IDNA] FaltstromとP.とホフマンとP.とA.M.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
[PUNYCODE] Costello, A.M., "Punycode: A Bootstring encoding of
Unicode for Internationalized Domain Names in
Applications (IDNA)", RFC 3492, March 2003.
[PUNYCODE]コステロ、午前、「Punycode:」 「Applications(IDNA)のInternationalized Domain Namesのためにユニコードをコード化するBootstring」、RFC3492、2003年3月。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[STRINGPREP] ホフマンとP.とM.Blanchet、「国際化しているストリング("stringprep")の準備」、RFC3454、2002年12月。
[NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)",
RFC 3491, March 2003.
[NAMEPREP] ホフマン、P.、およびM.Blanchet、「Nameprep:」 「国際化ドメイン名(IDN)のためのStringprepプロフィール」、RFC3491、2003年3月。
[IS10646] A product of ISO/IEC JTC1/SC2/WG2, Work Item
JTC1.02.18 (ISO/IEC 10646). It is a multipart
standard: Part 1, published as ISO/IEC 10646-
1:2000(E), covers the Architecture and Basic
Multilingual Plane, and Part 2, published as ISO/IEC
10646-2:2001(E), covers the supplementary
(additional) planes.
[IS10646] ISO/IEC JTC1/SC2/WG2、Work Item JTC1.02.18(ISO/IEC10646)の製品。 それは複合規格です: ISO/IEC10646- 1: 2000(E)として発行された第1部はArchitectureと基本多言語水準を含んでいます、そして、ISO/IEC10646-2: 2001(E)として発行されたPart2は補っている(追加)飛行機を覆っています。
[UNIHAN] Unicode Han Database, Unicode Consortium
ftp://ftp.unicode.org/Public/UNIDATA/Unihan.txt.
[UNIHAN]ユニコードハンデータベース、ユニコード共同体 ftp://ftp.unicode.org/Public/UNIDATA/Unihan.txt 。
[UNICODE] The Unicode Consortium, "The Unicode Standard Version
3.0," ISBN 0-201-61633-5. Unicode Standard Annex #28
(http://www.unicode.org/unicode/reports/tr28/)
defines Version 3.2 of the Unicode Standard, which is
definitive for IDNA and this document.
[ユニコード] ユニコード共同体、「ユニコード標準版3.0」、ISBN0-201-61633-5。 ユニコードStandard Annex#28( http://www.unicode.org/unicode/reports/tr28/ )はユニコードStandardのバージョン3.2を定義します。(IDNAとこのドキュメントに、Standardは決定的です)。
Konishi, et al. Informational [Page 29] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[29ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
[ISO7098] ISO 7098;1991 Information and documentation
Romanization of Chinese, ISO/TC46/SC2.
[ISO7098]ISO7098;1991情報と中国語のドキュメンテーションローマ化、ISO/TC46/SC2。
9.2. Informative References
9.2. 有益な参照
[IANA-LVTABLES] Internet Assigned Numbers Authority (IANA), IDN
Character Registry.
http://www.iana.org/assignments/idn/
IDNキャラクター登録[IANA-LVTABLES]インターネット規定番号権威(IANA)、 http://www.iana.org/assignments/idn/
[IDN-WG] IETF Internationalized Domain Names Working Group,
now concluded,idn@ops.ietf.org, James Seng, Marc
Blanchet, co-chairs, http://www.i-d-n.net/.
[IDN-WG] IETF Internationalized Domain Names作業部会、結論づけられた現在、 idn@ops.ietf.org 、ジェームスSeng、マークBlanchet、共同議長、 http://www.i-d-n.net/ 。
[UDRP] ICANN, "Uniform Domain Name Dispute Resolution
Policy", October 1999,
http://www.icann.org/udrp/udrp-policy-24oct99.htm
[UDRP]ICANN、「統一ドメイン名紛争処理方針」、1999年10月、 http://www.icann.org/udrp/udrp-policy-24oct99.htm
[ISO639] "ISO 639:1988 (E/F) Code for the representation of names
of languages", International Organization for
Standardization, 1st edition, 1988-04-01.
[ISO639]、「ISO、639:1988、言語の名前の表現のための(E/F)コード、」、国際標準化機構、最初の版、1988年4月1日。
10. Contributors
10. 貢献者
The formal responsibility for this document and the ideas it contains lie with K. Koniski, K. Huang, H. Qian, and Y. Ko. These authors are listed on the first page as authors of record, and they are the appropriate the long-term contacts for questions and comments on this RFC. On the other hand, J. Seng, J. Klensin, and W. Rickard served as editors of the document, transcribing and translating the ideas of the four authors and the teams they represented into the current written form. They were the primary contacts during the editing process, but not in the long term.
K.Koniski、K.ホアン、H.チエン、およびY.コーにはこのドキュメントへの正式な責任とそれが含む考えがあります。 これらの作者は記録の作者として最初のページに記載されています、そして、彼らは長期がこのRFCの質問とコメントのために連絡する好個です。 他方では、J.Seng、J.Klensin、およびW.リカードは4人の作者の考えを転写して、翻訳するドキュメントのエディタとそれらが現在の書かれたフォームに代理をしたチームとして勤めました。 それらは、編集の過程の間の一次的接触でしたが、長期で一次的接触であったというわけではありません。
Konishi, et al. Informational [Page 30] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[30ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
10.1. Authors' Addresses
10.1. 作者のアドレス
Kazunori KONISHI JPNIC Kokusai-Kougyou-Kanda Bldg 6F 2-3-4 Uchi-Kanda, Chiyoda-ku Tokyo 101-0047 Japan
F2-3-4Uchi-神田、KazunoriコニシJPNIC Kokusai-Kougyou-神田Bldg6東京日本千代田区101-0047
Phone: +81 49-278-7313 EMail: konishi@jp.apan.net
以下に電話をしてください。 +81 49-278-7313 メールしてください: konishi@jp.apan.net
Kenny HUANG TWNIC 3F, 16, Kang Hwa Street, Taipei Taiwan
F、16、カンHwa通り、ケニーホアンTWNIC3台湾台北
Phone: 886-2-2658-6510 EMail: huangk@alum.sinica.edu
以下に電話をしてください。 886-2-2658-6510 メールしてください: huangk@alum.sinica.edu
QIAN Hualin CNNIC No.6 Branch-box of No.349 Mailbox, Beijing 100080 Peoples Republic of China
チエンNo.349のHualin CNNIC No.6支店箱のMailbox、北京100080民族中華民国
EMail: Hlqian@cnnic.net.cn
メール: Hlqian@cnnic.net.cn
KO YangWoo PeaceNet Yangchun P.O. Box 81 Seoul 158-600 Korea
ノックアウトYangWoo PeaceNetヤンチュンP.O. Box81ソウル158-600韓国
EMail: yw@mrko.pe.kr
メール: yw@mrko.pe.kr
Konishi, et al. Informational [Page 31] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[31ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
10.2. Editors' Addresses
10.2. エディタのアドレス
James SENG 180 Lompang Road #22-07 Singapore 670180 Phone: +65 9638-7085
ジェームスSENG180Lompang道路#22-07シンガポール670180は以下に電話をします。 +65 9638-7085
EMail: jseng@pobox.org.sg
メール: jseng@pobox.org.sg
John C KLENSIN 1770 Massachusetts Avenue, No. 322 Cambridge, MA 02140 U.S.A.
No.322 ジョンC KLENSIN1770ケンブリッジ、MA02140マサチューセッツ通り(米国)
EMail: Klensin+ietf@jck.com
メール: Klensin+ ietf@jck.com
Wendy RICKARD The Rickard Group 16 Seminary Ave Hopewell, NJ 08525 USA
ウェンディーリカードリカードグループ16学校Aveホープウェル、ニュージャージー08525米国
EMail: rickard@rickardgroup.com
メール: rickard@rickardgroup.com
Konishi, et al. Informational [Page 32] RFC 3743 JET Guidelines for IDN April 2004
コニシ、他 情報[32ページ]のRFC3743は2004年4月にIDNのためのガイドラインを噴射します。
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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機能のための基金は現在、インターネット協会によって提供されます。
Konishi, et al. Informational [Page 33]
コニシ、他 情報[33ページ]
一覧
スポンサーリンク
