Internet Engineering Task Force (IETF) H. Alvestrand, Ed. Request for Comments: 5893 Google 分類: 標準化過程(Standards Track) C. Karp ISSN: 2070-1721 Swedish Museum of Natural History 2010年8月 IDNAにおける右から左に表記する用字 要旨 国際化ドメイン名(IDN)における右から左に表記する用字の使用は、幾つかの 課題を提起してきた。本文書は、2003 IDNA BIDI基準が幾つかの用字で直面した 問題や、同基準が不十分だった点に基づき、IDNAラベル用の新しいBIDIルールを 提案する。 Status of This Memo This is an Internet Standards Track document. 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 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5893. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Alvestrand & Karp Standards Track [Page 1] RFC 5893 IDNA Right to Left August 2010 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. 本文書の目的および適用範囲 . . . . . . . . . . . . . . . . 2 1.2. 背景と歴史 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. 本文書の以後の構成 . . . . . . . . . . . . . . . . . . . . 3 1.4. 専門用語 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Bidiルール . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Bidiルールが満たすべき要件 . . . . . . . . . . . . . . . . . . 6 4. RFC 3454に関して明らかとなった問題事例 . . . . . . . . . . . . 9 4.1. ディベヒ語 . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. イディッシュ語 . . . . . . . . . . . . . . . . . . . . . . 10 4.3. 数字を含む文字列 . . . . . . . . . . . . . . . . . . . . . 12 5. 問題を引き起こす状況とガイドライン . . . . . . . . . . . . . . 12 6. 解決が必要な他の問題 . . . . . . . . . . . . . . . . . . . . . 13 7. 互換性に関する考慮点 . . . . . . . . . . . . . . . . . . . . . 14 7.1. 後方互換性に関する考慮点 . . . . . . . . . . . . . . . . . 14 7.2. 前方互換性に関する考慮点 . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 1. はじめに 1.1. 本文書の目的および適用範囲 本文書の目的は、ユニコード形式(U-ラベル)で表記された国際化ドメイン名(IDN) ラベルが右から左に表記する用字の文字を含む場合に適用可能なルールを確立する ことである。これはIDNAプロトコル改訂版[RFC5891]の一部である。 ラベルが本文書の定義するルールに準拠し、かつ他の特定の条件を満たせば、 ユニコード双方向表示アルゴリズムを使用してもラベルが紛らわしく表示される 可能性を最小限に留められる。 有効なラベルの基準や許容される文字のリストなどは IDNA2008 に関する 一連の文書群に含まれる別の文書に記載がある。本文書は、通常右から左に 表記する用字のラベルに関する付加的な有効性の基準を規定する。 本仕様は、右から左に表記する用字の文字を含まないドメイン名に対して、何か 要件を加えるものではない。 Alvestrand & Karp Standards Track [Page 2] RFC 5893 IDNA Right to Left August 2010 1.2. 背景と歴史 IDNA2003の一部「Stringprep」仕様 [RFC3454] のセクション6で、Bidi アルゴリズムに関して以下のような記述がある。 3) 文字列がRandALCat文字を含む場合、RandALCat文字はその文字列の 最初の文字でなければならない(MUST)。また、RandALCat文字はその 文字列の最後の文字でなければならない(MUST)。 (RandALCat文字とは、右から左への表記方向が明確に定義された文字である)。 この禁止事項の背後にある論理は、表示されるドメイン名の全構成要素が 明確な表記方向の要求を持つことを保証することにあった。 しかし、この規定のために右から左に表記する用字の特定の単語が IDNラベルとして無効になった。そして言語に含まれる全ての単語が IDNラベルとして使用できなくなった事例が少なくとも1つあった (ディベヒ語の事例)。 これらの問題については、後でターナ文字を使うディベヒ語とヘブライ文字を 使うイディッシュ語を例に挙げて説明する。 RFC 3454は満たすべき要件を明確に記述していない。したがって、ルールを緩和 させても要件を満たし続けるかどうかの判定はできない。 本文書はRFC 3454のルールとは大きく異なるルールを規定するが、RFC 3454が 許容した正当なラベルは、本仕様でもほぼ全て許容する。(本仕様では許容 されない重要な例は、アラビア数字(AN)とヨーロッパ数字(EN)がRTLラベル内で 混在するラベルと、LTRラベル内でANを使用するラベルである。専門用語については セクション1.4参照のこと)。したがって、更新後のIDNA仕様の新しいルールを 使用しても運用上の影響は限定される。 1.3. 本文書の以後の構成 セクション2で「Bidiルール」を定義する。このルールをドメイン名ラベルに使用 すると、表記方向が混在する可能性のあるドメイン名を使用する場合に、それが どの程度安全かを検査できる。このルールを適用する最初の主要な対象は IDNA2008プロトコル[RFC5891]の一部である。 セクション3はBidiルールを定義する際の要件を詳しく説明する。 セクション4は新しいルールの正当性を証明する事例を提示する。 Alvestrand & Karp Standards Track [Page 3] RFC 5893 IDNA Right to Left August 2010 セクション5からセクション8では、異なる表記方向を持つ文字で構成された ドメイン名を扱う際に生じ得る様々な状況を論じる。 規定に関連するのはセクション1.4とセクション2だけである。 1.4. 専門用語 IDNAの概念を記述する際に使用する専門用語は Definitions 文書[RFC5890]で 定義する。 ユニコード文字のBidi特性を記述する際に使用する専門用語はユニコード標準 [Unicode52] から得たものである。 ユニコード標準は各文字のBidi特性を規定している。このBidi特性により、 ユニコードの双方向アルゴリズム[Unicode-UAX9]における各文字の振る舞いが 制御される。参考までにユニコードBidi特性が持つ値は以下のとおりである。 ・ L - 左から右 - LTR用字に含まれる大半の文字 ・ R - 右から左 - 非アラビアRTL用字に含まれる大半の文字 ・ AL - アラビア文字 - アラビア用字に含まれる大半の文字 ・ EN - ヨーロッパ数字 (0-9および拡張アラビア-インド数字) ・ ES - ヨーロッパ数字の区切り文字 (「+」および「-」) ・ ET - ヨーロッパ数字の終端文字 (通貨記号、ハッシュマーク、パーセント記号 など) ・ AN - アラビア数字。アラビア-インド数字を含むが拡張アラビア-インド数字は 含まない。 ・ CS - 共通の数字区切り文字 (. , / : など) ・ NSM - 文字送りを伴わない記号 - 大半の結合アクセント記号 ・ BN - 境界中立 - 制御文字(ZWNJ、ZWJその他) ・ B - 段落区切り文字 ・ S - セグメント区切り文字 ・ WS - SPACE文字を含む空白文字 ・ ON - 「@」、「&」、丸括弧、MIDDLE DOTを含む他の中立文字 Alvestrand & Karp Standards Track [Page 4] RFC 5893 IDNA Right to Left August 2010 ・ LRE, LRO, RLE, RLO, PDF - これらは「方向制御文字」で、IDNAラベルでは 使用されない 本文書において、ネットワーク上を文字が流れる順序またはファイル保存時に 文字を保存する順序を称して「ネットワークオーダ」という語を使用する。 ネットワークオーダにおけるラベル内の文字の関係を表す際には、「はじめに」 「次に」「前の」「~で始まる」「~で終わる」「~の前に」「~の後に」 といった語を使用する。 表示媒体に映し出される文字の順序を議論する場合には「ディスプレイオーダ」 という語を使用する。ディスプレイオーダにおけるラベル内の文字の関係を表す 際には、「左」「右」といった語を使用する。 ほとんどの場合、例の中で文字の方向を記述する際には、ユニコードBidiクラスの 略語を使用する。例えば、文字列 CS L はクラスCSの文字1文字と、クラスLの 文字1文字で構成される。いくつかの例で、大文字の文字はクラスRまたは クラスALに属し、小文字の文字はクラスLに属するという慣習を使用している。 例えば文字列 ABC.abc は3文字の右から左に表記する文字と、3文字の左から右に 表記する文字で構成される。 このような例における文字の方向は、文脈から判断される。例えば「ABC.abc は CBA.abcと表示される」という文の場合、最初の文字列例はネットワークオーダ であり、2番目の文字列例はディスプレイオーダである。 「段落(paragraph)」という語はユニコードBidi仕様 [Unicode-UAX9] で 定義された意味を持つものとして使用する。具体的に「左から右または 右から左のどちらかの方向で全体が統一された文のひと塊」という意味になる。 詳細は「ユニコード双方向アルゴリズム」[Unicode-UAX9]を参照のこと。 「RTL」と「LTR」は、それぞれ「右から左に表記」「左から右に表記」の省略形 である。 RTLラベルは、タイプR、AL、ANの文字を少なくとも1文字含むラベルである。 LTRラベルはRTLラベルではない任意のラベルである。 「Bidiドメイン名」は少なくとも1つのRTLラベルを含むドメイン名である。 (注: この定義はドットと右から左に表記する文字だけで構成されるドメイン名も 含む。「RTLドメイン名」という独立したカテゴリを提供してもこの仕様は 簡略化できないのでそうしなかった)。 Alvestrand & Karp Standards Track [Page 5] RFC 5893 IDNA Right to Left August 2010 2. Bidiルール 以下に示す6つの条件から成るルールをBidiドメイン名のラベルに適用する。 このルールが満たす要件はセクション3に記述されるものである。したがって、 ルールが要件を満たすためには、以下の条件全てを満たさなければならない。 1. 1文字目はBidi特性 L、R、ALのいずれかを持つ文字でなければならない。 R特性またはAL特性を持つ場合、それはRTLラベルであり、L特性を持つ場合は LTRラベルである。 2. RTLラベルはBidi特性 R、AL、AN、EN、ES、CS、ET、ON、BN、NSMの 文字のみを許容する。 3. RTLラベルの最後の文字はBidi特性 R、AL、EN、ANのいずれかであり、 その後にゼロ文字以上のBidi特性 NSMの文字が続くものでなければ ならない。 4. RTLラベルの中にENが存在する場合、ANが存在してはならない。 逆の場合も同様である。 5. LTRラベルはBidi特性 L、EN、ES、CS、ET、ON、BN、NSMの文字のみを 許容する。 6. LTRラベルの最後の文字はBidi特性 L、ENのいずれかであり、その後に ゼロ文字以上のBidi特性 NSMの文字が続くものでなければならない。 上記のルールにより、以下に示す事項を保証することができる。 ・ ルールを満たすラベルだけで構成されたドメイン名はセクション3の要件を 満たす。LTRラベルや純粋なASCIIラベルであってもテストしなければならない ことに注意してもらいたい。 ・ LDH ラベル(Definitions 文書[RFC5890]で定義される)とルールを満たす ラベルだけで構成されたドメイン名は、右から左に表記するラベルの すぐ後に続けてASCII数字で始まるラベルが現れない限り、 セクション3の要件を満たす。 他の組み合わせについては、何も保証しない。 3. Bidiルールが満たすべき要件 本文書はRFC 3454[RFC3454]とは異なり、Bidiルールの正当性を明確に検証できる 手段を提供する。ルールが満たすべき要件を提示するので、修正したルールが 要件を満たすかどうかをテストすることが可能となる。 Alvestrand & Karp Standards Track [Page 6] RFC 5893 IDNA Right to Left August 2010 本文書の全てにおいて、検討対象のラベルに含まれる文字列は、ユニコード 双方向アルゴリズム[Unicode-UAX9]を使用して表示されるものと仮定する。 提案する要件は以下のとおりである。 ・ ラベルの一意性 同じ段落に含まれる2つのラベルをディスプレイオーダで表示する場合、 段落がLTR表記方向を持つ場合・RTL表記方向を持つ場合のどちらの場合に おいても、ネットワークオーダで同じ文字の並びでないのならば、 ディスプレイオーダでも同じ文字の並びで表示すべきではない。 (これはRFC 3454でも明示された基準である)。 (RTL表記方向の段落で表示したラベルが、LTR表記方向の段落で異なる ラベルを表示したものと全く同じになる場合があるが、それでも 本基準を満たすことに注意してもらいたい)。 ・ 文字のグループ化 ひと続きのラベルを表示する際に、ユニコードBidiアルゴリズムを使用して 文字の順序を表示用に並び替える場合、文字列がLTR表記方向の段落に 埋め込まれている場合・RTL表記方向の段落に埋め込まれている場合の どちらの場合においても、各ラベルの文字は、ラベルの区切り文字で 区切られたグループ内にとどまるべきである。 幾つかのより強い要件は検討の後に却下された。ユニコード双方向アルゴリズムの 制約内で要件を満たすことは不可能と思われたからである。却下された要件は 以下のようなものである。 ・ 「ラベルの見え方は文字を埋め込むコンテキストの影響を受けるべきではない」。 ASCIIラベルですらこの要件を満たすことが不可能であることが 証明されている。「123-A」というラベルはRTLコンテキストと LTRコンテキストで異なって表示される。(どのみちこの例は有効では ないのだが)。 ・ 「ラベルの順序はネットワークオーダと整合すべきである」。 これは不可能だと証明されている。ドメイン名が(ネットワークオーダで) L1.R2.R3.L4 という構成である場合、LTRコンテキストでは L1.R3.R2.L4 と 表示される。(RTLコンテキストではL4.R3.R2.L1と表示される)。 ・ 「任意の2つの異なるドメイン名について、仮に両ドメインが異なる表記方向を 持つ場合であっても、表示した結果同じに見えるべきではない」 ドメイン名が(ネットワークオーダで)ABC.abcの場合、LTRコンテキストの ディスプレイオーダはCBA.abcになり、RTLコンテキストのディスプレイ オーダはCBA.abcとなる。一方でドメイン名が(ネットワークオーダで) abc.ABCの場合にはLTRコンテキストのディスプレイオーダがabc.CBAになり、 RTLコンテキストのディスプレイオーダはCBA.abcになる。これは不健全に 思える。 Alvestrand & Karp Standards Track [Page 7] RFC 5893 IDNA Right to Left August 2010 要件候補のひとつに問題があると思われていたが、本文書の提案ルールにしたがう 文字列の場合には、要件を満たすことが可能であると判明した。 ・ 「方向制御文字(LRE、RLE、RLO、LRO、PDF)が同じ段落で(ラベルの外で) 使用される場合に、文字のグループ化の要件を満たすべきである」。 これらの制御はユニコードBidiアルゴリズムの「sor」「eor」特性に影響を 与えるので、表示順序に予想困難な影響を与える。したがって、上記の 要件は、制御文字の使用がドメイン名の表示に影響を与えるかどうかを 明らかにするための付加的なテストが必要である。テストの結果、本文書が 提案するルールが許容する文字列については、方向制御はドメイン名の 表示に影響を与えないことが明らかになった。 これは要件として記述するほど重要とは思われなかったので要件として記述して いない。しかし、本文書で規定するルールを満足するラベルで構成された Bidiドメイン名にこのような性質があることを知っておくのは有益だろう。 以下の記述において、箇条書きの第一レベル(・)はルールまたは規定を記述し、 第二レベル( * )は解説を記述する。 文字のグループ化の要件は正式には以下のように記述できる。 ・ 「区切り文字」とは、ユニコードBidi特性 CS、WS、ONを持つ文字であると する。(これらは通常ラベルを区切るために使用される。FULL STOPと空白も 含む。これらをドメインラベルとしては許容しない)。 * ET は現実には大抵ドメイン名に隣接して現れるのだが、これは問題を 引き起こすので区切り文字としなかった。例えば、R CS L EN ETという コンテキスト(例えば A.a1%)の場合、ラベル L EN は文字のグループ化の 要件を満たさなくなる。 * ES は一般にHYPHEN-MINUSとしてラベル内に現れるが、区切り文字として 使用できることもある(例えばプラス記号)。しかしここでは区切り文字と せずそのまま残した。 ・ 「問題ないラベル」とは、要件を満たすかまたはBidi特性 R、RL、ANの いずれも含まないというどちらかの条件を満たし、かつBidi特性 ENで開始 されない(略すと「数字で始まらない」)ラベルとする。 Alvestrand & Karp Standards Track [Page 8] RFC 5893 IDNA Right to Left August 2010 任意の区切り文字をD1, D2とし、任意の問題ないラベルまたは空の文字列をS1, S2 とするとき、以下の条件が満たされればラベルXは文字のグループ化の要件を 満たす。 S1、D1、X、D2、S2をつなげた文字列をBidiアルゴリズムにしたがって 並び替える場合、段落全体がLTRの場合・段落全体がRTLの場合のどちらの 場合においても、並び替え後の文字列に含まれるXを構成する文字全てが D1とD2の間に存在しており、それ以外の文字はD2とD2の間に存在しない。 この定義は、S1とS2が本文書の定義に基づく「正当(legal)」なものだという 制約を持つので、自己参照であることに注意してもらいたい。これにより、 提案ルールを変更する際のテストが若干複雑になるが、提案ルールが基準を 満たすかどうかのテストには問題を生じない。 ラベルXの「長さがゼロ」の場合、ドメイン名ではない何かにドメイン名が 隣接しており、それが区切り文字で分け隔てられている状況を表す。 BNの位置に関する注記: ユニコード双方向アルゴリズムの規定では、BNは ディスプレイオーダではなくネットワークオーダで隣接する文字に影響を与えると しており、したがってBidi処理の際にBNコードは削除されたかのように扱われる。 ([Unicode-UAX9]セクション3.3.2のルールX9およびセクション5.3)。したがって 「並び替え後のBNの位置はどこか」といった問いは無意味であるから、 ルールの構築をしているここでは無視することにする。 ラベルの一意性の要件は、正式には以下のように記述できる。 異なるラベルXとYが、先に述べたテストのようにS1、D1、X、D2、S2または S1、D1、Y、D2、S2のように埋め込まれ、同じ表記方向を持つ段落で表示 される時、Bidiアルゴリズムによって両者が同じコードポイントの並びに 並び替えられるならば、ラベルXとYは共に正当ではない。 4. RFC 3454に関して明らかとなった問題事例 4.1. ディベヒ語 モルジブの公用語であるディベヒ語は、ターナ文字で記述する。ターナ文字は 表記方向の特性を含むアラビア文字の特性を持ち、母音であることを示すために、 子音の基底文字に発音区別記号を付加する。この記号は必須であり、また 2つの連続した母音と2つの連続した音節末子音(syllable-final consonants)は、 どちらも発音されない結合記号で示される。したがって、全てのディベヒ語の 単語は結合記号で終わる。 Alvestrand & Karp Standards Track [Page 9] RFC 5893 IDNA Right to Left August 2010 「computer」に相当する単語はローマ字綴りで「konpeetaru」となり、 以下のユニコードコードポイントの並びで表記される。 U+0786 THAANA LETTER KAAFU (AL) U+07AE THAANA OBOFILI (NSM) U+0782 THAANA LETTER NOONU (AL) U+07B0 THAANA SUKUN (NSM) U+0795 THAANA LETTER PAVIYANI (AL) U+07A9 THAANA LETTER EEBEEFILI (AL) U+0793 THAANA LETTER TAVIYANI (AL) U+07A6 THAANA ABAFILI (NSM) U+0783 THAANA LETTER RAA (AL) U+07AA THAANA UBUFILI (NSM) ユニコードデータベース[Unicode52]におけるU+07AAの方向性クラスはNSM (文字送りを伴わない記号)であり、RまたはALではない。したがって、 IDNA2003アルゴリズムに準拠した実装は「これはRandALCatではない」という メッセージを出力して文字列のエンコードを拒否する。 4.2. イディッシュ語 イディッシュ語はヘブライ文字で記述する幾つかの言語の中の1つである。(他には ヘブライ語やラディノ語などが挙げられる)。基本的に単子音文字(「abjad」とも 呼ばれる)なのだが、イディッシュ語は表記の際に母音性の拡張様式を 使用する。母音を示す方法は幾つがあるが、その中の1つに、ヘブライ語で 子音の文字にあらためて別の意味を持たせるというものがある。 他の文字は母音としても子音としても使用され、「ポイント」と称する結合記号 を使用して両者の区別を行う。最後に、幾つかの基底文字では1つで複数の異なる 母音を示すことができる。この場合も結合記号で区別する。ポイント付の文字は 単語の最終位置でも使用できるので、ラベルの終端場所でも使用できることが 求められる。これはイディッシュ文字列の不変の属性ではく、ディベヒ語の 場合よりもはるかに裁量の範囲が広い。 1930年代に、現在「YIVOユダヤ研究所(YIVO Institute for Jewish Research)」 として知られる組織が、20世紀早期から行われた作業で得られた幾つかの知見に 基いて、近代的標準イディッシュ語の正字法のルールを構築した。この成果は 「The Standardized Yiddish Orthography: Rules of Yiddish Spelling」[SYO]に まとめられており、近代的標準イディッシュに関係があると思われるあらゆる 文脈で、必須の記述として取り上げられている。この内容はルール構築後に出版 された正式なイディッシュ語辞書全てに独占的に採り入れられており、学術分野や 図書目録分野でも同様に支配的地位にある。 Alvestrand & Karp Standards Track [Page 10] RFC 5893 IDNA Right to Left August 2010 したがって、このレパートリーをIDNAが完全にサポートすのは適切と思われる。 単語の先頭および中間位置にある文字に関しては特に問題ない。 しかし、ポイント付文字は通常、先頭・中間に存在するのと同様に、単語の 末尾でも使用される。また、SYOレパートリーに含まれる文字は全て、例外である HEBREW LETTER PE (U+05E4)を除き、記号付き、記号なしどちらの形態でも現れる。 HEBREW LETTER PEに関しては、SYOが許容するのは HEBREW POINT DAGESH (U+05BC) と組み合わせてイディッシュ語にラテン文字「p」と等価な文字を提供する場合と、 HEBREW POINT RAFE (U+05BF)と組み合わせてラテン文字「f」と等価な文字を 提供する場合だけである。ただし、後者の文字は最終位置に現れる場合、 ポイントのつかない異字体 HEBREW LETTER FINAL PE (U+05E3) に変化する。 RFC 3454はRTL文字列の最後で結合記号を使用することを禁止しているので、 その結果SYOレパートリー使用に対して課せられる制約は、大まかにラテン文字で 構成する文字列は文字「p」で終えられないと言っているのと等しい。 また注記しなければならないのが、HEBREW LETTER PEとHEBREW POINT DAGESHの 組み合わせはSYO以前から(現在も並行して使用されている)伝統的なイディッシュ 正字法ほぼ全ての特性で、これがポイント付文字の最初のものであるということ である。 基本的な問題のより一般的な事例をYIVO頭文字語の表現に見ることができる。 これはヘブライ文字で YOD YOD HIRIQ VAV VAV ALEF QAMATS と表記 するもので、HIRIQとQAMATSは結合ポイントである。ユニコードコードポイントは 以下のとおりである。 U+05D9 HEBREW LETTER YOD (R) U+05B4 HEBREW POINT HIRIQ (NSM) U+05D5 HEBREW LETTER VAV (R) U+05D0 HEBREW LETTER ALEF (R) U+05B8 HEBREW POINT QAMATS (NSM) ユニコードデータベースのU+05B8 HEBREW POINT QAMATSの表記方向クラスは NSMなので、IDNA2003アルゴリズムはこの文字列を拒否する。 Alvestrand & Karp Standards Track [Page 11] RFC 5893 IDNA Right to Left August 2010 先に述べた結合文字は全て、部品となる結合前の文字がユニコードチャート (Unicord chart)のそれぞれ異なる場所に存在することに注意してもらいたい。 しかし、Stringprepを起動することにより、IDNA2003アルゴリズムはこれらの コードポイントを拒否するが、その理由はここでは論じない。 4.3. 数字を含む文字列 Stringprep仕様[RFC 3454]は、文字列の最初または最後の文字が カテゴリRまたはALに属する文字列であることを要求することで、 右から左に表記する文字を含む文字列が数字で終了することを禁止した。 文字列 ALEF 5 (HEBREW LETTER ALEF + DIGIT FIVE)および 5 ALEF を考える。 1つめの文字列をLTRコンテキストで表示すると、左から右に表示するので 5 ALEF となる(ALEFが先にきていることから、5は右から左に表記する文字と 解釈される)。一方で 5 ALEF はそのまま同じ順番で表示される(5はコンテキスト から方向が決められる)。これらのうち1つだけしか登録ラベルとして 許可すべきではないことは明らかだが、両方とも登録可能ラベルから除外する 必要はない。 5. 問題を引き起こす状況とガイドライン 先に述べたルールを満たすラベルを表示すると予想外の結果になることがある。 中でも最も重要なものは、Bidi特性ENの文字で始まるラベルの前にBidi特性AL, ANまたはRの文字で終了するラベルがくる場合である。 この場合、数字は右から左に表記する文字を含むラベル内に移動して見える ため、文字のグループ化の要件に違反する。 右から左に表記するラベルの後に現れるラベル自身がBidi基準を満たす場合、 あらゆる状況で要件は満たされる(これが基準が幾つかの状況でLを含む 文字列について言及した理由である)。しかし、IDNABIS WGは以下に示すような 理由から、これは要求できないと結論づけた。 ・ 数字で始まる膨大な量のASCIIドメイン名が存在する。これらを無効にする ことはできない。 ・ ドメイン名を段階的に構成する場合がある。例えば何かの文字列に 検索リストの内容を組み合わせるなどである。これらの構成処理は IDNA処理の後に行われるため、IDNA未対応の一部のコードが望ましくない 組み合わせを検知できなくなってしまう。 Alvestrand & Karp Standards Track [Page 12] RFC 5893 IDNA Right to Left August 2010 ・ ラベルが「安全な(safe)」ラベルの下位に登録されていたとしても、 「安全でない(unsafe)」ラベルを持つDNAME [RFC2672]が「安全な」 ラベルにポイントするかもしれない。したがって、一見有効に見える名前を 生成しても、それは基準を満たさないかもしれない。 ・ ワイルドカードによって、ゾーン所有者がそのラベルの存在を知らなくても 「有効」(正しく検索できる)なラベルが存在するという奇妙な状況を 作り出してしまう。したがって、ゾーン名が数字で始まりかつゾーン内に ワイルドカードを持つゾーンの所有者は、そのゾーン内にRTLラベルの 名前があるかどうかに関わらず、その名前がゾーン内で検索され応答を 返してしまうことを制御する手段がない。 これら望ましくない状況を全て許容しないようなルールの提案を試みることは せず、本文書は単に可能性について警告し、アプリケーション開発者達が 問題の生じる状況を回避するために適切と思える何らかの基準を選択できる ようにするにとどめる。 6. 解決が必要な他の問題 本文書は、異なるBidi特性を持つ文字で構成されたドメイン名を扱う場合に 必要なルールにのみ関与し、文字のBidi特性についてのみ考慮する。 右から左に表記する用字に関する他の全ての問題は、別途考慮・検討され なければならない。 そのような問題の1つに、数字と他のラベルとの分離の維持がある。 幾つかの用字では複数種類の数字を使用する。通常の場合はラテン数字と 用字固有の数字が使用される。しかしアラビア語の場合、2種類の 「アラビア-インド」数字を必要とする。 本文書のアルゴリズムは、AN-クラスの文字(U+0660からU+0669までの 「アラビア-インド数字」)とEN-クラスの文字(U+0030からU+0039までの 「ヨーロッパ」数字およびU+06F0からU+06F9までの「拡張アラビア-インド数字」) が同時に現れることを許容しない。それでも、例えばベンガル数字(U+09E6から U+09EFまで)とグジャラート数字(U+0AE6からU+0AEFまで)のような、どちらも BidiクラスLの特性を持つ数字の混在を防ぐことはできない。 ラベルに含まれる数字の混在を制限するルールを作りたいレジストリまたは 用字コミュニティは、レジストリレベルでそれらの制約を指定することができる。 幾つかのルールについては、プロトコルレベルで規定される。 もう1つの問題は、LTRとRTLが混在する、またはRTLラベルのみで構成された IDNの適切な表示に関することである。 Alvestrand & Karp Standards Track [Page 13] RFC 5893 IDNA Right to Left August 2010 アプリケーションがドメイン名のラベルの中に埋め込まれたフォーマット コードを使用してドメイン名を表示することを期待するのは非現実的である。 (一例を挙げると、文字列が連続的に入力される場合に、そこからドメイン名を 識別する信頼できるアルゴリズムは存在しない)。したがって、ディスプレイ オーダはBidiアルゴリズムから判定される。その場合、(ネットワークオーダで) R1.R2.ltrという並びはLTRコンテキストでは2R.1R.ltrと表示されるので、 階層的な順序でラベルが表示されることを期待するユーザを驚かせるかもしれない。 LTR文字列とRTL文字列が混在する環境で作業したことのある人々はさして 驚かないかもしれない。繰り返すが本文書はこの問題の解決を試みるものではない。 7. 互換性に関する考慮点 7.1. 後方互換性に関する考慮点 既存の標準に対する変更と同様に、本文書の変更が導入された際に既存の実装で 発生する事柄を考慮することは重要である。以下に示すように、問題を引き起こす 状況が予想される。 ・ 本文書が新たに許容したラベルを入力する際に旧来のプログラムを使用 する場合。旧来のプログラムが、入力されたラベルがRFC 3454に違反 していないかを検査すると、幾つかのラベルは許容されないので、 そのようなラベルを含むドメイン名はアクセスできない状態になるだろう。 ・ 本文書が新たに許容したラベルを表示する要求を旧来のプログラムが受け、 表示前にRFC 3454に違反していないかを検査する場合。プログラムは 何らかの形でフォールバックを実行するので、大体の場合ラベルは A-ラベル形式で表示されるだろう。 ・ 本文書が新たに許容したラベルを旧来のプログラムが表示しようと試みる 場合。旧来のプログラムが持つラベルの最後の文字を表示するコードと ラベルの中程にある文字を表示するコードと異なる場合、表示される結果は 一貫性がなく混乱を招くだろう。 最後に挙げた項目の事例の1つは、プログラムが文字列の表記方向を決定する ために、文字列の1文字目ではなく(ネットワークオーダの)最後の文字を 検査することを選択した場合である。プログラムがNSM文字を発見し、 左から右に表記する文字列であるとしてその文字列を表示しようと試みると、 結果として表示される文字列は面白いものになるかもしれないが、実用的では ないだろう。 著者らは、これらの事例があったとしても、特定の言語でIDNラベルとして 必要な単語文字列の使用を禁止し続けるよりは害が少ないと信じる。 Alvestrand & Karp Standards Track [Page 14] RFC 5893 IDNA Right to Left August 2010 本仕様は、ASCIIのみで構成されたラベルにおいて、ヨーロッパ数字で始まる ラベルを禁止しない。これは既に使用されている膨大なラベルと衝突するし、 本仕様の対象範囲がRTLラベルから全ラベルへと広がってしまうためである。 対象範囲を限定した結果生じる問題点はセクション5に記述した。レジストリや プライベートなゾーンの管理者は、任意のRTLラベルの登録を許可する前に、 特定の条件を検査することができる。一般に、あるゾーンの上位ゾーン名が 数字で始まるラベルの場合、そのゾーンに右から左に表記する文字列を 登録することを許容しないのが最善である。 7.2. 前方互換性に関する考慮点 本文書は、意図的にユニコードBidi特性に限定して規定を行っている。 条件が基準を満たすかの判定はユニコードBidiアルゴリズムに依存するが、 このアルゴリズムが劇的に変更される可能性はあまりない。 しかし、任意の文字列の有効性の判定はユニコードBidi特性の値に依存するが、 これはユニコードコンソーシアムが不変であると宣言したものではない。 さらに、任意の文字に対するアルゴリズムの振る舞いは言語学的にも文化的にも 影響を受けやすいものであるから、今後のユニコード標準では特定のユニコード 文字に割り当てられたBidi特性が変更されるかもしれない。それが起こるのは 稀であることが望ましいとしてもである。 本文書はこの問題の解決策を提案しない。 9. セキュリティに関する考慮点 表記方向が混在するテキストを表示させた際の挙動は、ユーザをひどく 驚かせるものになり得る。例えば、テキストの一部をカット&ペーストした 場合、ペースト先が異なる表記方向コンテキストで、文字をペーストした結果、 ペースト場所から離れた場所にある文字列の表示位置が変わってしまい、 結果としてテキストが異なって表示される可能性がある。 しかし、これはドメイン名の表示固有の問題ではない。 新しいIDNAプロトコル、特に新しいBidiルールは、現在のIDNAコンテキスト内では 許容されない文字列を許容する。IDNA2003の実装とIDNA2008の実装でラベルの 解釈が異なることにより、セキュリティリスクが生じる可能性がある。しかし、 このリスクの具体的な事例を予想することは困難である。 何らかの合理的な計算の試み、例えばIDNAが処理するIDのハッシュ値の計算は ネットワークオーダの情報を使用する。したがって、ここで提案する 新しいルールの影響を受けない。 問題は生じないと信じているが、RFC 3454 IDNAの禁止事項に関する特定の 知識に基づいて書かれた表示ルーチンがある場合、「後方互換性」の項で 記述した潜在的な問題により、新たな混乱が生じるかもしれない。 Alvestrand & Karp Standards Track [Page 15] RFC 5893 IDNA Right to Left August 2010 9. Acknowledgements While the listed editors held the pen, this document represents the joint work and conclusions of an ad hoc design team. In addition to the editors, this consisted of, in alphabetic order, Tina Dam, Patrik Faltstrom, and John Klensin. Many further specific contributions and helpful comments were received from the people listed below, and others who have contributed to the development and use of the IDNA protocols. The particular formulation of the Bidi rule in Section 2 was suggested by Matitiahu Allouche. The team wishes, in particular, to thank Roozbeh Pournader for calling its attention to the issue with the Thaana script, Paul Hoffman for pointing out the need to be explicit about backwards compatibility considerations, Ken Whistler for suggesting the basis of the formalized "Character Grouping" requirement, Mark Davis for commentary, Erik van der Poel for careful review, comments, and verification of the rulesets, Marcos Sanz, Andrew Sullivan, and Pete Resnick for reviews, and Vint Cerf for chairing the working group and contributing massively to getting the documents finished. 10. References 10.1. Normative References [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [Unicode-UAX9] The Unicode Consortium, "Unicode Standard Annex #9: Unicode Bidirectional Algorithm", September 2009, . [Unicode52] The Unicode Consortium. The Unicode Standard, Version 5.2.0, defined by: "The Unicode Standard, Version 5.2.0", (Mountain View, CA: The Unicode Consortium, 2009. ISBN 978-1-936213-00-9). . Alvestrand & Karp Standards Track [Page 16] RFC 5893 IDNA Right to Left August 2010 10.2. Informative References [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999. [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010. [SYO] "The Standardized Yiddish Orthography: Rules of Yiddish Spelling, 6th ed., New York, ISBN 0-914512-25-0", 1999. Authors' Addresses Harald Tveit Alvestrand (editor) Google Beddingen 10 Trondheim, 7014 Norway EMail: harald@alvestrand.no Cary Karp Swedish Museum of Natural History Frescativ. 40 Stockholm, 10405 Sweden Phone: +46 8 5195 4055 Fax: EMail: ck@nic.museum Alvestrand & Karp Standards Track [Page 17]