[要約] RFC 8753は、新しいUnicodeバージョンのためのIDNA（国際化ドメイン名）のレビューに関するものです。その目的は、新しいUnicodeバージョンの変更がIDNAにどのように影響するかを評価し、適切なアップデートを提案することです。
Internet Engineering Task Force (IETF) J. Klensin
Request for Comments: 8753
Updates: 5892 P. Fältström
Category: Standards Track Netnod
ISSN: 2070-1721 April 2020
Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions
新しいUnicodeバージョンのアプリケーションの国際化ドメイン名（IDNA）レビュー
Abstract
概要
The standards for Internationalized Domain Names in Applications (IDNA) require a review of each new version of Unicode to determine whether incompatibilities with prior versions or other issues exist and, where appropriate, to allow the IETF to decide on the trade-offs between compatibility with prior IDNA versions and compatibility with Unicode going forward. That requirement, and its relationship to tables maintained by IANA, has caused significant confusion in the past. This document makes adjustments to the review procedure based on experience and updates IDNA, specifically RFC 5892, to reflect those changes and to clarify the various relationships involved. It also makes other minor adjustments to align that document with experience.
アプリケーションの国際化ドメイン名（IDNA）の標準では、以前のバージョンとの非互換性やその他の問題が存在するかどうかを判断し、適切な場合、IETFとの互換性のトレードオフを決定できるようにするために、Unicodeの新しいバージョンをそれぞれレビューする必要があります。以前のIDNAバージョンと今後のUnicodeとの互換性。この要件と、IANAによって維持されるテーブルとの関係により、過去に大きな混乱が生じています。このドキュメントは、経験に基づいてレビュー手順を調整し、IDNA、特にRFC 5892を更新して、それらの変更を反映し、関連するさまざまな関係を明確にします。また、ドキュメントを経験に合わせて調整するために、その他の小さな調整も行います。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8753.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8753で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Brief History of IDNA Versions, the Review Requirement, and RFC
5982
3. The Review Model
3.1. Review Model Part I: Algorithmic Comparison
3.2. Review Model Part II: New Code Point Analysis
4. IDNA Assumptions and Current Practice
5. Derived Tables Published by IANA
6. Editorial Clarification to RFC 5892
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Summary of Changes to RFC 5892
Appendix B. Background and Rationale for Expert Review Procedure
for New Code Point Analysis
Acknowledgments
Authors' Addresses
The standards for Internationalized Domain Names in Applications (IDNA) require a review of each new version of Unicode to determine whether incompatibilities with prior versions or other issues exist and, where appropriate, to allow the IETF to decide on the trade-offs between compatibility with prior IDNA versions and compatibility with Unicode [Unicode] going forward. That requirement, and its relationship to tables maintained by IANA, has caused significant confusion in the past (see Section 3 and Section 4 for additional discussion of the question of appropriate decisions and the history of these reviews). This document makes adjustments to the review procedure based on nearly a decade of experience and updates IDNA, specifically the document that specifies the relationship between Unicode code points and IDNA derived properties [RFC5892], to reflect those changes and to clarify the various relationships involved.
アプリケーションの国際化ドメイン名（IDNA）の標準では、以前のバージョンとの非互換性やその他の問題が存在するかどうかを判断し、適切な場合はIETFとの互換性のトレードオフを決定できるように、Unicodeの新しいバージョンをそれぞれ確認する必要があります。以前のIDNAバージョンと今後のUnicode [Unicode]との互換性。この要件と、IANAによって維持されるテーブルとの関係により、過去に大きな混乱が生じています（適切な決定の問題とこれらのレビューの履歴の詳細については、セクション3とセクション4を参照してください）。このドキュメントは、10年近くの経験に基づいてレビュー手順を調整し、IDNA、特にUnicodeコードポイントとIDNA派生プロパティ[RFC5892]の間の関係を指定するドキュメントを更新して、それらの変更を反映し、関連するさまざまな関係を明確にします。
This specification does not change the requirement that registries at all levels of the DNS tree take responsibility for the labels they insert in the DNS, a level of responsibility that requires allowing only a subset of the code points and strings allowed by the IDNA protocol itself. That requirement is discussed in more detail in a companion document [RegRestr].
この仕様は、DNSツリーのすべてのレベルのレジストリがDNSに挿入するラベルに対して責任を持つという要件を変更しません。これは、IDNAプロトコル自体によって許可されるコードポイントと文字列のサブセットのみを許可する必要がある責任のレベルです。この要件については、関連ドキュメント[RegRestr]で詳しく説明しています。
Terminology note: In this document, "IDNA" refers to the current version as described in RFC 5890 [RFC5890] and subsequent documents and sometimes known as "IDNA2008". Distinctions between it and the earlier version are explicit only where they are necessary for understanding the relationships involved, e.g., in Section 2.
用語の注記：このドキュメントでは、「IDNA」はRFC 5890 [RFC5890]および後続のドキュメントに記載されている現在のバージョンを指し、「IDNA2008」と呼ばれることもあります。それと以前のバージョンの違いは、たとえばセクション2で関係を理解するために必要な場合にのみ明示されます。
The original, now-obsolete, version of IDNA, commonly known as "IDNA2003" [RFC3490] [RFC3491], was defined in terms of a profile of a collection of IETF-specific tables [RFC3454] that specified the usability of each Unicode code point with IDNA. Because the tables themselves were normative, they were intrinsically tied to a particular version of Unicode. As Unicode evolved, the IDNA2003 standard would have required the creation of a new profile for each new version of Unicode, or the tables would have fallen further and further behind.
オリジナルの、現在は廃止されたバージョンのIDNA（一般に「IDNA2003」[RFC3490] [RFC3491]として知られている）は、各Unicodeコードの使いやすさを指定するIETF固有のテーブル[RFC3454]のコレクションのプロファイルに関して定義されました。 IDNAでポイントします。テーブル自体は規範的であったため、本質的に特定のバージョンのUnicodeに関連付けられていました。 Unicodeの進化に伴い、IDNA2003標準では、Unicodeの新しいバージョンごとに新しいプロファイルを作成する必要がありました。そうでない場合、テーブルはますます遅れてしまいます。
When IDNA2003 was superseded by the current version, known as IDNA2008 [RFC5890], a different strategy, one that was property-based rather than table-based, was adopted for a number of reasons, of which the reliance on normative tables was not dominant [RFC4690]. In the IDNA2008 model, the use of normative tables was replaced by a set of procedures and rules that operated on Unicode properties [Unicode-properties] and a few internal definitions to determine the category and status, and hence an IDNA-specific "derived property", for any given code point. Those rules are, in principle, independent of Unicode versions. They can be applied to any version of Unicode, at least from approximately version 5.0 forward, to yield an appropriate set of derived properties. However, the working group that defined IDNA2008 recognized that not all of the Unicode properties were completely stable and that, because the criteria for new code points and property assignment used by the Unicode Consortium might not precisely align with the needs of IDNA, there were possibilities of incompatible changes to the derived property values. More specifically, there could be changes that would make previously disallowed labels valid, previously valid labels disallowed, or that would be disruptive to IDNA's defining rule structure. Consequently, IDNA2008 provided for an expert review of each new version of Unicode with the possibility of providing exceptions to the rules for particular new code points, code points whose properties had changed, and newly discovered issues with the IDNA2008 collection of rules. When problems were identified, the reviewer was expected to notify the IESG. The assumption was that the IETF would review the situation and modify IDNA2008 as needed, most likely by adding exceptions to preserve backward compatibility (see Section 3.1).
IDNA2003がIDNA2008 [RFC5890]として知られる現在のバージョンに取って代わられたとき、テーブルベースではなくプロパティベースである別の戦略が、規範的なテーブルへの依存が支配的でなかったいくつかの理由で採用されました[RFC4690]。 IDNA2008モデルでは、規範的なテーブルの使用は、カテゴリとステータスを決定するためにUnicodeプロパティ[Unicode-properties]といくつかの内部定義を操作する一連の手順とルールに置き換えられたため、IDNA固有の「派生プロパティ」 "、任意のコードポイント。これらのルールは、原則として、Unicodeバージョンから独立しています。これらは、少なくともバージョン5.0以降の任意のバージョンのUnicodeに適用して、適切な一連の派生プロパティを生成できます。ただし、IDNA2008を定義したワーキンググループは、すべてのUnicodeプロパティが完全に安定しているわけではなく、Unicodeコンソーシアムが使用する新しいコードポイントとプロパティ割り当ての基準がIDNAのニーズと正確に一致しない場合があるため、可能性があることを認識しました。派生プロパティ値への互換性のない変更。具体的には、以前は許可されていなかったラベルを有効にしたり、以前に有効だったラベルを許可しないようにしたり、IDNAの定義ルール構造を破壊したりする可能性があります。その結果、IDNA2008は、特定の新しいコードポイント、プロパティが変更されたコードポイント、およびIDNA2008のルールコレクションで新たに発見された問題について、ルールに例外を提供する可能性があるUnicodeの新しいバージョンごとに専門家によるレビューを提供しました。問題が特定された場合、査読者はIESGに通知することが期待されていました。 IETFは状況を確認し、必要に応じてIDNA2008を変更するという想定でした。おそらく、下位互換性を維持するために例外を追加することです（セクション3.1を参照）。
For the convenience of the community, IDNA2008 also provided that IANA would maintain copies of calculated tables resulting from each review, showing the derived properties for each code point. Those tables were expected to be helpful, especially to those without the facilities to easily compute derived properties themselves. Experience with the community and those tables has shown that they have been confused with the normative tables of IDNA2003: the IDNA2008 tables published by IANA have never been normative, and statements about IDNA2008 being out of date with regard to some Unicode version because the IANA tables have not been updated are incorrect or meaningless.
コミュニティの便宜のために、IDNA2008は、IANAが各レビューから得られた計算されたテーブルのコピーを維持し、各コードポイントの派生プロパティを示すことも規定しています。これらのテーブルは、特に派生プロパティ自体を簡単に計算する機能がないテーブルに役立つと期待されていました。コミュニティとそれらのテーブルの経験は、それらがIDNA2003の規範的なテーブルと混同されていることを示しています。IANAによって発行されたIDNA2008テーブルは規範的ではなく、IANA2008に関する記述は、IANAテーブルが一部のUnicodeバージョンに関して古くなっている更新されていないのは不正確または無意味です。
While the text has sometimes been interpreted differently, IDNA2008 actually calls for two types of review when a new Unicode version is introduced. One is an algorithmic comparison of the set of derived properties calculated from the new version of Unicode to the derived properties calculated from the previous one to determine whether incompatible changes have occurred. The other is a review of newly assigned code points to determine whether any of them require special treatment (e.g., assignment of what IDNA2008 calls contextual rules) and whether any of them violate any of the assumptions underlying the IDNA2008 derived property calculations. Any of the cases of either review might require either per-code point exceptions or other adjustments to the rules for deriving properties that are part of RFC 5892. The subsections below provide a revised specification for the review procedure.
テキストの解釈が異なる場合がありますが、IDNA2008では、新しいUnicodeバージョンが導入されたときに、実際には2種類のレビューが必要です。 1つは、互換性のない変更が発生したかどうかを判断するために、Unicodeの新しいバージョンから計算された派生プロパティのセットと以前のプロパティから計算された派生プロパティのアルゴリズム比較です。もう1つは、新しく割り当てられたコードポイントのレビューであり、それらのいずれかが特別な処理（IDNA2008がコンテキストルールと呼ぶものの割り当てなど）を必要とするかどうか、およびそれらのいずれかがIDNA2008派生プロパティ計算の基礎となる仮定に違反していないかどうかを判断します。どちらのレビューの場合でも、コードポイントごとの例外またはRFC 5892の一部であるプロパティを取得するためのルールに対するその他の調整が必要になる場合があります。以下のサブセクションでは、レビュー手順の改訂された仕様を示します。
Unless the IESG or the designated expert team concludes that there are special problems or unusual circumstances, these reviews will be performed only for major Unicode versions (those numbered NN.0, e.g., 12.0) and not for minor updates (e.g., 12.1).
IESGまたは指定された専門家チームが特別な問題または異常な状況があると結論しない限り、これらのレビューはメジャーUnicodeバージョン（NN.0、たとえば12.0）に対してのみ実行され、マイナーアップデート（たとえば、12.1）に対しては実行されません。
As can be seen in the detailed descriptions in the following subsections, proper review will require a team of experts that has both broad and specific skills in reviewing Unicode characters and their properties in relation to both the written standards and operational needs. The IESG will need to appoint experts who can draw on the broader community to obtain the necessary skills for particular situations. See the IANA Considerations (Section 7) for details.
次のサブセクションの詳細な説明からわかるように、適切なレビューには、Unicode文字とその特性を書面の基準と運用上のニーズの両方に関してレビューする幅広い特定のスキルを持つ専門家チームが必要です。 IESGは、より広いコミュニティを利用して特定の状況に必要なスキルを習得できる専門家を任命する必要があります。詳細については、IANAの考慮事項（セクション7）を参照してください。
Section 5.1 of RFC 5892 is the description of the process for creating the initial IANA tables. It is noteworthy that, while it can be read as strongly implying new reviews and new tables for versions of Unicode after 5.2, it does not explicitly specify those reviews or, e.g., the timetable for completing them. It also indicates that incompatibilities are to be "flagged for the IESG" but does not specify exactly what the IESG is to do about them and when. For reasons related to the other type of review and discussed below, only one review was completed, documented [RFC6452], and a set of corresponding new tables installed. That review, which was for Unicode 6.0, found only three incompatibilities; the consensus was to ignore them (not create exceptions in IDNA2008) and to remain consistent with computations based on current (Unicode 6.0) properties rather than preserving backward compatibility within IDNA. The 2018 review (for Unicode 11.0 and versions in between it and 6.0) [IDNA-Unicode12] also concluded that Unicode compatibility, rather than IDNA backward compatibility, should be maintained. That decision was partially driven by the long period between reviews and the concern that table calculations by others in the interim could result in unexpected incompatibilities if derived property definitions were then changed. See Section 4 for further discussion of these preferences.
RFC 5892のセクション5.1は、初期IANAテーブルを作成するプロセスの説明です。これは、5.2以降のバージョンのUnicodeの新しいレビューと新しいテーブルを強く暗示するものとして読むことができますが、それらのレビューや、たとえば、それらを完了するためのタイムテーブルを明示的に指定していないことは注目に値します。また、非互換性に「IESGのフラグを立てる」必要があることを示していますが、IESGが非互換性について何をいつ行うのかを正確に指定していません。他のタイプのレビューに関連して以下で説明する理由により、[RFC6452]に文書化された1つのレビューのみが完了し、対応する新しいテーブルのセットがインストールされました。 Unicode 6.0を対象としたこのレビューでは、3つの非互換性のみが見つかりました。コンセンサスはそれらを無視し（IDNA2008で例外を作成しない）、IDNA内の下位互換性を維持するのではなく、現在の（Unicode 6.0）プロパティに基づく計算と一貫性を保つことでした。 2018レビュー（Unicode 11.0およびそのバージョンと6.0の間のバージョン）[IDNA-Unicode12]も、IDNAの下位互換性ではなく、Unicode互換性を維持する必要があると結論付けました。この決定の一部は、レビュー間の長い期間と、暫定的に他のユーザーによるテーブルの計算が、派生プロパティの定義が変更された場合に予期しない非互換性を引き起こす可能性があるという懸念によって生じました。これらの設定の詳細については、セクション4を参照してください。
The second type of review, which is not clearly explained in RFC 5892, is intended to identify cases in which newly added or recently discovered problematic code points violate the design assumptions of IDNA, to identify defects in those assumptions, or to identify inconsistencies (from an IDNA perspective) with Unicode commitments about assignment, properties, and stability of newly added code points. One example of this type of review was the discovery of new code points after Unicode 7.0 that were potentially visually equivalent, in the same script, to previously available code point sequences [IAB-Unicode7-2015] [IDNA-Unicode7].
RFC 5892で明確に説明されていない2番目のタイプのレビューは、新しく追加された、または最近発見された問題のあるコードポイントがIDNAの設計仮定に違反するケースを特定すること、それらの仮定の欠陥を特定すること、または不一致を特定することを目的としています。 IDNAの観点）新しく追加されたコードポイントの割り当て、プロパティ、および安定性に関するUnicodeの取り組み。このタイプのレビューの1つの例は、同じスクリプトで、以前に利用可能なコードポイントシーケンス[IAB-Unicode7-2015] [IDNA-Unicode7]と視覚的に同等である可能性のある、Unicode 7.0以降の新しいコードポイントの発見でした。
Because multiple perspectives on Unicode and writing systems are required, this review will not be successful unless it is done by a team. Finding one all-knowing expert is improbable, and a single expert is unlikely to produce an adequate analysis. Rather than any single expert being the sole source of analysis, the designated expert (DE) team needs to understand that there will always be gaps in their knowledge, to know what they don't know, and to work to find the expertise that each review requires. It is also important that the DE team maintains close contact with the Area Directors (ADs) and that the ADs remain aware of the team's changing needs, examining and adjusting the team's membership over time, with periodic reexamination at least annually. It should also be recognized that, if this review identifies a problem, that problem is likely to be complex and/or involve multiple trade-offs. Actions to deal with it are likely to be disruptive (although perhaps not to large communities of users), or to leave security risks (opportunities for attacks and inadvertent confusion as expected matches do not occur), or to cause excessive reliance on registries understanding and taking responsibility for what they are registering [RFC5894] [RegRestr]. The latter, while a requirement of IDNA, has often not worked out well in the past.
Unicodeと書記体系については複数の視点が必要であるため、チームで行わない限り、このレビューは成功しません。すべてを知っている専門家を1人見つけることはほとんどありませんし、単一の専門家が適切な分析を行うことはまずありません。指定されたエキスパート（DE）チームは、単一のエキスパートが唯一の分析ソースであるのではなく、常に知識にギャップがあることを理解し、彼らが知らないことを知り、それぞれの専門知識を見つけるために取り組む必要があります。レビューが必要です。また、DEチームがエリアディレクター（AD）と緊密に連絡を取り合い、ADがチームの変化するニーズを認識し続け、少なくとも年に1度は定期的にチームのメンバーシップを調査および調整することが重要です。このレビューで問題が特定された場合、その問題は複雑であるか、複数のトレードオフを伴う可能性が高いことも認識しておく必要があります。これに対処するためのアクションは、（おそらくユーザーの大規模なコミュニティではないかもしれませんが）破壊的であるか、セキュリティリスクを残す（予想される一致が発生しないため、攻撃と不注意による混乱の可能性があります）、またはレジストリの理解に過度に依存する可能性があります。彼らが何を登録するかについて責任を取る[RFC5894] [RegRestr]。後者はIDNAの要件ですが、過去にはうまくいかないことがよくあります。
Because resolution of problems identified by this part of the review may take some time even if that resolution is to add additional contextual rules or to disallow one or more code points, there will be cases in which it will be appropriate to publish the results of the algorithmic review and to provide IANA with corresponding tables, with warnings about code points whose status is uncertain until there is IETF consensus about how to proceed. The affected code points should be considered unsafe and identified as "under review" in the IANA tables until final derived properties are assigned.
レビューのこの部分で特定された問題の解決には、コンテキストルールを追加したり、1つ以上のコードポイントを禁止したりする場合でも時間がかかることがあるため、結果を公開することが適切な場合があります。アルゴリズムのレビューと対応するテーブルをIANAに提供するため、続行する方法についてIETFの合意が得られるまでステータスが不明なコードポイントに関する警告が表示されます。影響を受けるコードポイントは安全ではないと見なされ、最終的な派生プロパティが割り当てられるまで、IANAテーブルで「レビュー中」として識別されます。
At the time the IDNA2008 documents were written, the assumption was that, if new versions of Unicode introduced incompatible changes, the Standard would be updated to preserve backward compatibility for users of IDNA. For most purposes, this would be done by adding to the table of exceptions associated with Rule G [RFC5892a].
IDNA2008ドキュメントが作成された時点では、新しいバージョンのUnicodeに互換性のない変更が導入された場合、標準はIDNAのユーザーの下位互換性を維持するために更新されると想定されていました。これはほとんどの目的で、ルールG [RFC5892a]に関連する例外のテーブルに追加することで行われます。
This has not been the practice in the reviews completed subsequent to Unicode 5.2, as discussed in Section 3. Incompatibilities were identified in Unicode 6.0 [RFC6452] and in the cumulative review leading to tables for Unicode 11.0 [IDNA-Unicode11]. In all of those cases, the decision was made to maintain compatibility with Unicode properties rather than with prior versions of IDNA.
これは、セクション3で説明したように、Unicode 5.2以降に完了したレビューでは行われていません。非互換性は、Unicode 6.0 [RFC6452]およびUnicode 11.0 [IDNA-Unicode11]のテーブルに至る累積レビューで確認されました。これらすべてのケースで、以前のバージョンのIDNAではなくUnicodeプロパティとの互換性を維持することが決定されました。
If an algorithmic review detects changes in Unicode after version 12.0 that would break compatibility with derived properties associated with prior versions of Unicode or changes that would preserve compatibility within IDNA at the cost of departing from current Unicode specifications, those changes must be captured in documents expected to be published as Standards Track RFCs so that the IETF can review those changes and maintain a historical record.
アルゴリズムレビューにより、バージョン12.0以降のUnicodeの変更が検出され、以前のバージョンのUnicodeに関連する派生プロパティとの互換性が失われる場合や、現在のUnicode仕様からの逸脱を犠牲にしてIDNA内の互換性を維持する変更が行われる場合は、それらの変更を予想されるドキュメントに取り込む必要があります。 IETFがこれらの変更を確認し、履歴レコードを維持できるように、Standards Track RFCとして公開されます。
The community has now made decisions and updated tables for Unicode 6.0 [RFC6452], done catch-up work between it and Unicode 11.0 [IDNA-Unicode11], and completed the review and tables for Unicode 12.0 [IDNA-Unicode12]. The decisions made in those cases were driven by preserving consistency with Unicode and Unicode property changes for reasons most clearly explained by the IAB [IAB-Unicode-2018]. These actions were not only at variance with the language in RFC 5892 but were also inconsistent with commitments to the registry and user communities to ensure that IDN labels that were once valid under IDNA2008 would remain valid, and previously invalid labels would remain invalid, except for those labels that were invalid because they contained unassigned code points.
コミュニティはUnicode 6.0 [RFC6452]の決定とテーブルの更新を行い、Unicode 11.0 [IDNA-Unicode11]との間に追いつき作業を行い、Unicode 12.0 [IDNA-Unicode12]のレビューとテーブルを完了しました。これらのケースで行われた決定は、IAB [IAB-Unicode-2018]によって最も明確に説明された理由により、UnicodeおよびUnicodeプロパティの変更との一貫性を維持することによって推進されました。これらのアクションは、RFC 5892の言語と異なるだけでなく、レジストリとユーザーコミュニティへのコミットメントとも一致しませんでした。これにより、IDNA2008でかつて有効であったIDNラベルが有効であり、以前は無効であったラベルが無効のままになります。割り当てられていないコードポイントが含まれていたために無効であったラベル。
This document restores and clarifies that original language and intent: absent extremely strong evidence on a per-code point basis that preserving the validity status of possible existing (or prohibited) labels would cause significant harm, Unicode changes that would affect IDNA derived properties are to be reflected in IDNA exceptions that preserve the status of those labels. There is one partial exception to this principle. If the new code point analysis (see Section 3.2) concludes that some code points or collections of code points should be further analyzed, those code points, and labels including them, should be considered unsafe and used only with extreme caution because the conclusions of the analysis may change their derived property values and status.
このドキュメントは、元の言語と意図を復元して明確にします。コードポイントごとに非常に強力な証拠がないと、存在する可能性のある（または禁止されている）ラベルの有効性ステータスを維持すると重大な害が発生します。IDNA派生プロパティに影響を与えるUnicodeの変更は、次のとおりです。これらのラベルのステータスを保持するIDNA例外に反映されます。この原則には1つの部分的な例外があります。新しいコードポイント分析（セクション3.2を参照）で、一部のコードポイントまたはコードポイントのコレクションをさらに分析する必要があると結論付けた場合、それらのコードポイントおよびそれらを含むラベルは安全でないと見なし、非常に注意して使用する必要があります。分析により、派生したプロパティ値とステータスが変更される場合があります。
As discussed above, RFC 5892 specified that derived property tables be provided via an IANA registry. Perhaps because most IANA registries are considered normative and authoritative, that registry has been the source of considerable confusion, including the incorrect assumption that the absence of published tables for versions of Unicode later than 6.0 meant that IDNA could not be used with later versions. That position was raised in multiple ways, not all of them consistent, especially in the ICANN context [ICANN-LGR-SLA].
上記のように、RFC 5892は、派生プロパティテーブルがIANAレジストリを介して提供されることを指定しています。おそらく、ほとんどのIANAレジストリは規範的で信頼できると見なされているため、そのレジストリはかなりの混乱の元になっています。たとえば、6.0以降のバージョンのUnicode用に公開されたテーブルがないため、IDNAをそれ以降のバージョンでは使用できないという誤った仮定が含まれています。その立場は、特にICANNのコンテキスト[ICANN-LGR-SLA]において、すべてが一貫しているわけではなく、複数の方法で提起されました。
If the changes specified in this document are not successful in significantly mitigating the confusion about the status of the tables published by IANA, serious consideration should be given to eliminating those tables entirely.
このドキュメントで指定された変更がIANAによって公開されたテーブルのステータスに関する混乱を大幅に軽減することに成功しない場合、それらのテーブルを完全に削除することを真剣に検討する必要があります。
This section updates RFC 5892 to provide fixes for known applicable errata and omissions. In particular, verified RFC Editor Erratum 3312 [Err3312] provides a clarification to Appendix A and A.1 in RFC 5892. That clarification is incorporated below.
このセクションでは、RFC 5892を更新して、既知の該当する正誤表と記載漏れの修正を提供します。特に、検証済みのRFCエディターErratum 3312 [Err3312]は、RFC 5892の付録AおよびA.1を明確化しています。その明確化は以下に組み込まれています。
1. In Appendix A, add a new paragraph after the paragraph that begins "The code point...". The new paragraph should read:
1. 付録Aで、「コードポイント...」で始まる段落の後に新しい段落を追加します。新しい段落は次のようになります。
| For the rule to be evaluated to True for the label, it MUST be
| evaluated separately for every occurrence of the code point in
| the label; each of those evaluations must result in True.
2. In Appendix A.1, replace the "Rule Set" by
2. 付録A.1では、「ルールセット」を
Rule Set:
False;
If Canonical_Combining_Class(Before(cp)) .eq. Virama
Then True;
If cp .eq. \u200C And
RegExpMatch((Joining_Type:{L,D})(Joining_Type:T)*cp
(Joining_Type:T)*(Joining_Type:{R,D})) Then True;
For the algorithmic review described in Section 3.1, the IESG is to appoint a designated expert [RFC8126] with appropriate expertise to conduct the review and to supply derived property tables to IANA. As provided in Section 5.2 of the Guidelines for Writing IANA Considerations [RFC8126], the designated expert is expected to consult additional sources of expertise as needed. For the code point review, the expertise will be supplied by an IESG-designated expert team as discussed in Section 3.2 and Appendix B. In both cases, the experts should draw on the expertise of other members of the community as needed. In particular, and especially if there is no overlap of the people holding the various roles, coordination with the IAB-appointed liaison to the Unicode Consortium will be essential to mitigate possible errors due to confusion.
セクション3.1で説明されているアルゴリズムレビューの場合、IESGは、レビューを実施し、派生プロパティテーブルをIANAに提供するための適切な専門知識を持つ指定エキスパート[RFC8126]を任命します。 IANAの考慮事項を作成するためのガイドライン[RFC8126]のセクション5.2に記載されているように、指定された専門家は、必要に応じて追加の専門家に相談することが期待されています。コードポイントのレビューでは、セクション3.2および付録Bで説明されているように、専門知識はIESGが指定した専門家チームによって提供されます。どちらの場合も、専門家は必要に応じてコミュニティの他のメンバーの専門知識を利用する必要があります。特に、さまざまな役割を担う人々の重複がない場合は特に、IABが指定したUnicodeコンソーシアムへの連絡との調整が、混乱によるエラーの可能性を軽減するために不可欠です。
As discussed in Section 5, IANA has modified the IDNA tables collection [IANA-IDNA-Tables] by identifying them clearly as non-normative, so that a "current" or "correct" version of those tables is not implied, and by pointing to this document for an explanation. IANA has published tables supplied by the IETF for all Unicode versions through 11.0, retaining all older versions and making them available. Newer tables will be constructed as specified in this document and then made available by IANA. IANA has changed the title of that registry from "IDNA Parameters", which is misleading, to "IDNA Rules and Derived Property Values".
セクション5で説明したように、IANAはIDNAテーブルコレクション[IANA-IDNA-Tables]を非規範的であると明確に識別し、これらのテーブルの「現在の」または「正しい」バージョンを意味せず、説明については、このドキュメントをご覧ください。 IANAは、IETFが提供する11.0までのすべてのUnicodeバージョンのテーブルを公開し、すべての古いバージョンを保持し、それらを使用可能にしています。新しいテーブルは、このドキュメントで指定されているとおりに作成され、IANAによって利用可能になります。 IANAは、そのレジストリのタイトルを、誤解を招くような「IDNAパラメータ」から「IDNAルールと派生プロパティ値」に変更しました。
The "Note" in that registry says:
そのレジストリの「メモ」は言う：
| IDNA does not require that applications and libraries, either for
| registration/storage or lookup, support any particular version of
| Unicode. Instead, they are required to use derived property
| values based on calculations associated with whatever version of
| Unicode they are using elsewhere in the application or library.
| For the convenience of application and library developers and
| others, the IETF has supplied, and IANA maintains, derived
| property tables for several version of Unicode as listed below.
| It should be stressed that these are not normative in that, in
| principle, an application can do its own calculations and these
| tables can change as IETF understanding evolves. By contrast, the
| list of code points requiring contextual rules and the associated
| rules are normative and should be treated as updates to the list
| in RFC 5892.
As long as the intent is preserved, the text of that note may be changed in the future at IANA's discretion.
意図が維持される限り、その注記のテキストはIANAの裁量により将来変更される可能性があります。
IANA's attention is called to the introduction, in Section 3.2, of a temporary "under review" category to the PVALID, DISALLOWED, etc., entries in the tables.
IANAの注意は、3.2節で、表のPVALID、DISALLOWEDなどのエントリの一時的な「検討中」カテゴリの紹介に呼び出されます。
Applying the procedures described in this document and understanding of the clarifications it provides should reduce confusion about IDNA requirements. Because past confusion has provided opportunities for bad behavior, the effect of these changes should improve Internet security to at least some small extent.
このドキュメントで説明されている手順を適用し、それが提供する説明を理解することで、IDNA要件に関する混乱を減らすことができます。過去の混乱は悪い行動の機会を提供してきたので、これらの変更の影響は少なくともある程度までインターネットのセキュリティを改善するはずです。
Because of the preference to keep the derived property value stable (as specified in RFC 5892 and discussed in Section 4), the algorithm used to calculate those derived properties does change as explained in Section 3. If these changes are not taken into account, the derived property value will change, and the implications might have negative consequences, in some cases with security implications. For example, changes in the calculated derived property value for a code point from either DISALLOWED to PVALID or from PVALID to DISALLOWED can cause changes in label interpretation that would be visible and confusing to end users and might enable attacks.
（RFC 5892で指定され、セクション4で説明されているように）派生プロパティ値を安定に保つための設定により、これらの派生プロパティの計算に使用されるアルゴリズムは、セクション3で説明されているように変更されます。これらの変更が考慮されない場合、派生プロパティ値は変化し、その影響は、場合によってはセキュリティに影響を与えるマイナスの結果をもたらす可能性があります。たとえば、コードポイントの計算された派生プロパティ値がDISALLOWEDからPVALIDに、またはPVALIDからDISALLOWEDに変更されると、ラベルの解釈に変化が生じ、エンドユーザーにはわかりにくくなり、攻撃が可能になる可能性があります。
[IANA-IDNA-Tables] IANA, "IDNA Rules and Derived Property Values", <https://www.iana.org/assignments/idna-tables>.
[IANA-IDNA-Tables] IANA、「IDNAルールと派生プロパティ値」、<https://www.iana.org/assignments/idna-tables>。
[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, DOI 10.17487/RFC5892, August 2010, <https://www.rfc-editor.org/info/rfc5892>.
[RFC5892] Faltstrom、P。、編、「アプリケーションのUnicodeコードポイントと国際化ドメイン名（IDNA）」、RFC 5892、DOI 10.17487 / RFC5892、2010年8月、<https://www.rfc-editor.org / info / rfc5892>。
[RFC5892a] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", Section 2.7, RFC 5892, August 2010, <https://www.rfc-editor.org/rfc/rfc5892.txt>.
[RFC5892a] Faltstrom、P。、編、「アプリケーションのUnicodeコードポイントと国際化ドメイン名（IDNA）」、セクション2.7、RFC 5892、2010年8月、<https://www.rfc-editor.org/rfc /rfc5892.txt>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[Unicode] The Unicode Consortium, "The Unicode Standard (Current Version)", <http://www.unicode.org/versions/latest/>. The link given will always access the current version of the Unicode Standard, independent of its version number or date.
[Unicode] Unicodeコンソーシアム、「The Unicode Standard（Current Version）」、<http://www.unicode.org/versions/latest/>。指定されたリンクは、バージョン番号や日付に関係なく、常にUnicode標準の現在のバージョンにアクセスします。
[Unicode-properties] The Unicode Consortium, "The Unicode Standard Version 11.0", Section 3.5, 2018, <https://www.unicode.org/versions/Unicode11.0.0/>.
[Unicode-properties] Unicodeコンソーシアム、「The Unicode Standard Version 11.0 "、Section 3.5、2018、<https://www.unicode.org/versions/Unicode11.0.0/>。
[Err3312] RFC Errata, Erratum ID 3312, RFC 5892, <https://www.rfc-editor.org/errata/eid3312>.
[Err3312] RFC Errata、Erratum ID 3312、RFC 5892、<https://www.rfc-editor.org/errata/eid3312>。
[IAB-Unicode-2018] Internet Architecture Board (IAB), "IAB Statement on Identifiers and Unicode", 15 March 2018, <https://www.iab.org/documents/correspondence-reports-documents/2018-2/iab-statement-on-identifiers-and-unicode/>.
[IAB-Unicode-2018] Internet Architecture Board（IAB）、「IAB Statement on Identifiers and Unicode」、2018年3月15日、<https://www.iab.org/documents/correspondence-reports-documents/2018-2/ iab-statement-on-identifiers-and-unicode />。
[IAB-Unicode7-2015] Internet Architecture Board (IAB), "IAB Statement on Identifiers and Unicode 7.0.0", 11 February 2015, <https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-statement-on-identifiers-and-unicode-7-0-0/>.
[IAB-Unicode7-2015] Internet Architecture Board（IAB）、「IAB Statement on Identifiers and Unicode 7.0.0」、2015年2月11日、<https://www.iab.org/documents/correspondence-reports-documents/2015 -2 / iab-statement-on-identifiers-and-unicode-7-0-0 />。
[ICANN-LGR-SLA] Internet Corporation for Assigned Names and Numbers (ICANN), "Proposed IANA SLAs for Publishing LGRs/IDN Tables", 10 June 2019, <https://www.icann.org/public-comments/proposed-iana-sla-lgr-idn-tables-2019-06-10-en>.
[ICANN-LGR-SLA] Internet Corporation for Assigned Names and Numbers（ICANN）、「Proposed IANA SLAs Publishing Publishing LGRs / IDN Tables」、2019年6月10日、<https://www.icann.org/public-comments/proposed -iana-sla-lgr-idn-tables-2019-06-10-en>。
[IDNA-Unicode7] Klensin, J. and P. Faltstrom, "IDNA Update for Unicode 7.0 and Later Versions", Work in Progress, Internet-Draft, draft-klensin-idna-5892upd-unicode70-05, 8 October 2017, <https://tools.ietf.org/html/draft-klensin-idna-5892upd-unicode70-05>.
[IDNA-Unicode7] Klensin、J。およびP. Faltstrom、「Unicode 7.0以降のバージョンのIDNAアップデート」、Work in Progress、Internet-Draft、draft-klensin-idna-5892upd-unicode70-05、2017年10月8日、< https://tools.ietf.org/html/draft-klensin-idna-5892upd-unicode70-05>。
[IDNA-Unicode11] Faltstrom, P., "IDNA2008 and Unicode 11.0.0", Work in Progress, Internet-Draft, draft-faltstrom-unicode11-08, 11 March 2019, <https://tools.ietf.org/html/draft-faltstrom-unicode11-08>.
[IDNA-Unicode11] Faltstrom、P。、「IDNA2008およびUnicode 11.0.0」、Work in Progress、Internet-Draft、draft-faltstrom-unicode11-08、2019年3月11日、<https://tools.ietf.org/ html / draft-faltstrom-unicode11-08>。
[IDNA-Unicode12] Faltstrom, P., "IDNA2008 and Unicode 12.0.0", Work in Progress, Internet-Draft, draft-faltstrom-unicode12-00, 11 March 2019, <https://tools.ietf.org/html/draft-faltstrom-unicode12-00>.
[IDNA-Unicode12] Faltstrom、P。、「IDNA2008およびUnicode 12.0.0」、Work in Progress、Internet-Draft、draft-faltstrom-unicode12-00、2019年3月11日、<https://tools.ietf.org/ html / draft-faltstrom-unicode12-00>。
[RegRestr] Klensin, J. and A. Freytag, "Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations", Work in Progress, Internet-Draft, draft-klensin-idna-rfc5891bis-05, 29 August 2019, <https://tools.ietf.org/html/draft-klensin-idna-rfc5891bis-05>.
[RegRestr] Klensin、J。およびA. Freytag、「アプリケーションの国際化ドメイン名（IDNA）：レジストリの制限と推奨事項」、進行中の作業、インターネットドラフト、draft-klensin-idna-rfc5891bis-05、2019年8月29日、 <https://tools.ietf.org/html/draft-klensin-idna-rfc5891bis-05>。
[RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, DOI 10.17487/RFC1766, March 1995, <https://www.rfc-editor.org/info/rfc1766>.
[RFC1766] Alvestrand、H。、「言語の識別のためのタグ」、RFC 1766、DOI 10.17487 / RFC1766、1995年3月、<https://www.rfc-editor.org/info/rfc1766>。
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, DOI 10.17487/RFC3282, May 2002, <https://www.rfc-editor.org/info/rfc3282>.
[RFC3282] Alvestrand、H。、「コンテンツ言語ヘッダー」、RFC 3282、DOI 10.17487 / RFC3282、2002年5月、<https://www.rfc-editor.org/info/rfc3282>。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, DOI 10.17487/RFC3454, December 2002, <https://www.rfc-editor.org/info/rfc3454>.
[RFC3454] Hoffman、P.およびM. Blanchet、「Preparation of Internationalized Strings（ "stringprep"）」、RFC 3454、DOI 10.17487 / RFC3454、2002年12月、<https://www.rfc-editor.org/info/ rfc3454>。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, DOI 10.17487/RFC3490, March 2003, <https://www.rfc-editor.org/info/rfc3490>.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「Internationalizing Domain Names in Applications（IDNA）」、RFC 3490、DOI 10.17487 / RFC3490、2003年3月、<https：//www.rfc-editor .org / info / rfc3490>。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, DOI 10.17487/RFC3491, March 2003, <https://www.rfc-editor.org/info/rfc3491>.
[RFC3491] Hoffman、P.およびM. Blanchet、「Nameprep：国際化ドメイン名（IDN）のStringprepプロファイル」、RFC 3491、DOI 10.17487 / RFC3491、2003年3月、<https://www.rfc-editor.org / info / rfc3491>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>。
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006, <https://www.rfc-editor.org/info/rfc4690>.
[RFC4690] Klensin、J.、Faltstrom、P.、Karp、C。、およびIAB、「レビューおよび国際化ドメイン名（IDN）の推奨事項」、RFC 4690、DOI 10.17487 / RFC4690、2006年9月、<https：// www.rfc-editor.org/info/rfc4690>。
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5646]フィリップス、A。、エド。 M.デイビス編、「言語を識別するためのタグ」、BCP 47、RFC 5646、DOI 10.17487 / RFC5646、2009年9月、<https://www.rfc-editor.org/info/rfc5646>。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、DOI 10.17487 / RFC5890、2010年8月、<https://www.rfc-editor.org/info/ rfc5890>。
[RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, <https://www.rfc-editor.org/info/rfc5894>.
[RFC5894] Klensin、J。、「アプリケーションの国際化ドメイン名（IDNA）：背景、説明、および理論的根拠」、RFC 5894、DOI 10.17487 / RFC5894、2010年8月、<https://www.rfc-editor.org/ info / rfc5894>。
[RFC6452] Faltstrom, P., Ed. and P. Hoffman, Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0", RFC 6452, DOI 10.17487/RFC6452, November 2011, <https://www.rfc-editor.org/info/rfc6452>.
[RFC6452] Faltstrom、P.、Ed。およびP.ホフマン編、「アプリケーションのUnicodeコードポイントと国際化ドメイン名（IDNA）-Unicode 6.0」、RFC 6452、DOI 10.17487 / RFC6452、2011年11月、<https://www.rfc-editor.org / info / rfc6452>。
Other than the editorial correction specified in Section 6, all of the changes in this document are concerned with the reviews for new versions of Unicode and with the IANA Considerations in Section 5 of [RFC5892], particularly Section 5.1 of [RFC5892]. Whether the changes are substantive or merely clarifications may be somewhat in the eye of the beholder, so the list below should not be assumed to be comprehensive. At a very high level, this document clarifies that two types of review were intended and separates them for clarity. This document also restores the original (but so far unobserved) default for actions when code point derived properties change. For this reason, this document effectively replaces Section 5.1 of [RFC5892] and adds or changes some text so that the replacement makes better sense.
セクション6で指定された編集上の修正を除いて、このドキュメントのすべての変更は、Unicodeの新しいバージョンのレビューと、[RFC5892]のセクション5のIANAの考慮事項、特に[RFC5892]のセクション5.1に関するものです。変更が実質的であるか単なる説明であるかにかかわらず、見る人の目にはある程度の可能性があるため、以下のリストは包括的であると想定すべきではありません。非常に高いレベルで、このドキュメントは2種類のレビューが意図されていたことを明確にし、明確にするためにそれらを分離しています。このドキュメントでは、コードポイントの派生プロパティが変更されたときに、アクションの元の（ただし、これまでのところ観察されていない）デフォルトを復元します。このため、このドキュメントは、[RFC5892]のセクション5.1を効果的に置き換え、一部のテキストを追加または変更して、置き換えが意味をなすようにします。
Changes or clarifications that may be considered important include:
重要と見なされる可能性のある変更または説明には、次のものがあります。
* Separated the new Unicode version review into two explicit parts and provided for different review methods and, potentially, asynchronous outcomes.
* 新しいUnicodeバージョンのレビューを2つの明示的な部分に分割し、さまざまなレビュー方法と、場合によっては非同期の結果を提供しました。
* Specified a DE team, not a single designated expert, for the code point review.
* コードポイントレビューのために、単一の指定された専門家ではなく、DEチームを指定しました。
* Eliminated the de facto requirement for the (formerly single) designated expert to be the same person as the IAB's liaison to the Unicode Consortium, but called out the importance of coordination.
* （以前は単一であった）指定された専門家がIABのUnicodeコンソーシアムへの連絡と同じ人物であるという事実上の要件を排除しましたが、調整の重要性を強調しました。
* Created the "Status" field in the IANA tables to inform the community about specific potentially problematic code points. This change creates the ability to add information about such code points before IETF review is completed instead of having the review process hold up the use of the new Unicode version.
* 特定の潜在的に問題のあるコードポイントについてコミュニティに通知するために、IANAテーブルに「ステータス」フィールドを作成しました。この変更により、レビュープロセスで新しいUnicodeバージョンの使用を保留する代わりに、IETFレビューが完了する前にそのようなコードポイントに関する情報を追加する機能が作成されます。
* In part because Unicode is now on a regular one-year cycle rather than producing major and minor versions as needed, to avoid overloading the IETF's internationalization resources, and to avoid generating and storing IANA tables for trivial changes (e.g., the single new code point in Unicode 12.1), the review procedure is applied only to major versions of Unicode unless exceptional circumstances arise and are identified.
* 部分的には、Unicodeが必要に応じてメジャーバージョンとマイナーバージョンを生成するのではなく、通常の1年サイクルになり、IETFの国際化リソースの過負荷を回避し、簡単な変更（たとえば、単一の新しいコードポイント）のためのIANAテーブルの生成と保存を回避しますUnicode 12.1）では、例外的な状況が発生して識別されない限り、レビュー手順はUnicodeのメジャーバージョンにのみ適用されます。
Appendix B. Background and Rationale for Expert Review Procedure for New Code Point Analysis
付録B.新しいコードポイント分析のエキスパートレビュー手順の背景と根拠
The expert review procedure for new code point analysis described in Section 3.2 is somewhat unusual compared to the examples presented in the Guidelines for Writing IANA Considerations [RFC8126]. This appendix explains that choice and provides the background for it.
セクション3.2で説明されている新しいコードポイント分析のエキスパートレビュー手順は、IANAの考慮事項を記述するためのガイドライン[RFC8126]で提示されている例と比較すると、やや珍しいものです。この付録では、その選択について説明し、その背景を説明します。
Development of specifications to support use of languages and writing systems other than English (and Latin script) -- so-called "internationalization" or "i18n" -- has always been problematic in the IETF, especially when requirements go beyond simple coding of characters (e.g., RFC 3629 [RFC3629]) or simple identification of languages (e.g., RFC 3282 [RFC3282] and the earlier RFC 1766 [RFC1766]). A good deal of specialized knowledge is required, knowledge that comes from multiple fields and that requires multiple perspectives. The work is not obviously more complex than routing, especially if one assumes that routing work requires a solid foundation in graph theory or network optimization, or than security and cryptography, but people working in those areas are drawn to the IETF and people from the fields that bear on internationalization typically are not.
英語（およびラテン文字）以外の言語およびライティングシステムの使用をサポートする仕様の開発（いわゆる「国際化」または「i18n」）は、特に要件が文字の単純なコーディングを超えている場合、IETFで常に問題を抱えています（たとえば、RFC 3629 [RFC3629]）または言語の単純な識別（たとえば、RFC 3282 [RFC3282]および以前のRFC 1766 [RFC1766]）。複数の分野から得られ、複数の視点を必要とする専門知識がかなり必要です。作業はルーティングよりも明らかに複雑ではありません。特に、ルーティング作業にグラフ理論またはネットワーク最適化の強固な基盤が必要であると想定した場合、またはセキュリティと暗号化よりも複雑ではありません。国際化に関係するものは通常そうではありません。
As a result, we have often thought we understood a problem, generated a specification or set of specifications, but then have been surprised by unanticipated (by the IETF) issues. We then needed to tune and often revise our specification. The language tag work that started with RFC 1766 is a good example of this: broader considerations and requirements led to later work and a much more complex and finer-grained system [RFC5646].
その結果、私たちは問題を理解し、仕様または仕様のセットを生成したとしばしば思っていましたが、予期しない（IETFによる）問題に驚いていました。次に、仕様を調整し、頻繁に改訂する必要がありました。 RFC 1766で始まった言語タグの作業は、この良い例です。幅広い考慮事項と要件により、後の作業と、より複雑で細かいシステム[RFC5646]につながりました。
Work on IDNs further increased the difficulties because many of the decisions that led to the current version of IDNA require understanding the DNS, its constraints, and, to at least some extent, the commercial market of domain names, including various ICANN efforts.
IDNAの現在のバージョンに至るまでの多くの決定は、DNS、その制約、そして少なくともある程度は、さまざまなICANNの取り組みを含むドメイン名の商用市場を理解する必要があるため、IDNの作業はさらに困難を増しました。
The net result of these factors is that it is extremely unlikely that the IESG will ever find a designated expert whose knowledge and understanding will include everything that is required.
これらの要因の最終結果は、IESGが指定された専門家を見つけ、その知識と理解に必要なすべてのものが含まれる可能性が非常に低くなることです。
Consequently, Section 7 and other discussions in this document specify a DE team that is expected to have the broad perspective, expertise, and access to information and community in order to review new Unicode versions and to make consensus recommendations that will serve the Internet well. While we anticipate that the team will have one or more leaders, the structure of the team differs from the suggestions given in Section 5.2 of the Guidelines for Writing IANA Considerations [RFC8126] since neither the team's formation nor its consultation is left to the discretion of the designated expert, nor is the designated expert solely accountable to the community. A team that contains multiple perspectives is required, the team members are accountable as a group, and any nontrivial recommendations require team consensus. This also differs from the common practice in the IETF of "review teams" from which a single member is selected to perform a review: the principle for these reviews is team effort.
したがって、このドキュメントのセクション7およびその他のディスカッションでは、新しいUnicodeバージョンを確認し、インターネットに役立つコンセンサスの推奨を行うために、幅広い視点、専門知識、および情報とコミュニティへのアクセスを期待されているDEチームを指定しています。チームには1人以上のリーダーがいると予想されますが、チームの構造は、IANAの考慮事項を作成するためのガイドライン[RFC8126]のセクション5.2に示されている提案とは異なります。指定された専門家、または指定された専門家だけがコミュニティに対して責任を負うものではありません。複数の視点を含むチームが必要であり、チームメンバーはグループとして責任を負い、重要でない提案にはチームの合意が必要です。これはまた、レビューを実行するために単一のメンバーが選択される「レビューチーム」のIETFにおける一般的な慣行とは異なります。これらのレビューの原則はチームの努力です。
Acknowledgments
謝辞
This document was inspired by extensive discussions within the I18N Directorate of the IETF Applications and Real-Time (ART) area in the first quarter of 2019 about sorting out the reviews for Unicode 11.0 and 12.0. Careful reviews by Joel Halpern and text suggestions from Barry Leiba resulted in some clarifications.
このドキュメントは、2019年の第1四半期に、IETFアプリケーションおよびリアルタイム（ART）領域のI18N理事会内でUnicode 11.0および12.0のレビューを整理することについての広範な議論に触発されました。 Joel Halpernによる慎重なレビューとBarry Leibaからのテキストの提案により、いくつかの明確化が行われました。
Thanks to Christopher Wood for catching some editorial errors that persisted until rather late in the document's life cycle and to Benjamin Kaduk for catching and raising a number of questions during Last Call. Some of the issues they raised have been reflected in the document; others did not appear to be desirable modifications after further discussion, but the questions were definitely worth raising and discussing.
ドキュメントのライフサイクルのかなり後期まで続くいくつかの編集エラーをキャッチしてくれたChristopher Woodに、ラストコール中に多くの質問をキャッチして提起してくれたBenjamin Kadukに感謝します。彼らが提起した問題のいくつかは文書に反映されています。他の人々はさらなる議論の後に望ましい修正であるように見えませんでしたが、質問は間違いなく提起して議論する価値がありました。
Authors' Addresses
著者のアドレス
John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 United States of America
John C Klensin 1770 Massachusetts Ave、Ste 322 Cambridge、MA 02140アメリカ合衆国
Phone: +1 617 245 1457
Email: john-ietf@jck.com
Patrik Fältström Netnod Greta Garbos Väg 13 SE-169 40 Solna Sweden
PatrikFältströmNetnod Greta GarbosVäg13 SE-169 40 Solnaスウェーデン
Phone: +46 70 6059051
Email: paf@netnod.se