ネットワーク作業部会 A. Phillips, Ed. コメント募集: 5646 Lab126 BCP: 47 M. Davis, Ed. 廃止対象: 4646 Google カテゴリ: ベスト・カレント・プラクティス 2009年9月 言語を識別するためのタグ 要旨 この文書では、情報オブジェクトで使用されている言語を示すことが 望ましい場合に使用する言語タグの構造、内容、構築方法、および 意味論について説明する。また、言語タグで使用する値を登録する 方法、および私的な交換のためにユーザー定義の拡張を作成する方法 についても説明する。 このメモの位置付け この文書は、インターネット・コミュニティのためのインターネットの ベスト・カレント・プラクティスを規定し、改善のための議論および提案を 求める。このメモの配布には制限がない。 Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Phillips & Davis ベスト・カレント・プラクティス [1ページ]
RFC 5646 言語タグ 2009年9月 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 言語タグ . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. 構文 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. 言語タグの書式 . . . . . . . . . . . . . . . . . . 6 2.2. 言語サブタグの出典と解釈 . . . . . . . . . . . . . . . . 8 2.2.1. 主言語サブタグ . . . . . . . . . . . . . . . . . . . 9 2.2.2. 拡張言語サブタグ . . . . . . . . . . . . . . . . . 11 2.2.3. 文字体系サブタグ . . . . . . . . . . . . . . . . . 12 2.2.4. 地域サブタグ . . . . . . . . . . . . . . . . . . . 13 2.2.5. 変種サブタグ . . . . . . . . . . . . . . . . . . . 15 2.2.6. 拡張サブタグ . . . . . . . . . . . . . . . . . . . 16 2.2.7. 私的利用サブタグ . . . . . . . . . . . . . . . . . 18 2.2.8. 旧来および冗長な登録 . . . . . . . . . . . . . . . 18 2.2.9. 適合性のクラス . . . . . . . . . . . . . . . . . . 19 3. レジストリの形式と保守 . . . . . . . . . . . . . . . . . . 21 3.1. IANA 言語サブタグレジストリの形式 . . . . . . . . . . 21 3.1.1. ファイル形式 . . . . . . . . . . . . . . . . . . . 21 3.1.2. レコードおよびフィールドの定義 . . . . . . . . . . 23 3.1.3. Type フィールド . . . . . . . . . . . . . . . . . . 26 3.1.4. Subtag および Tag フィールド . . . . . . . . . . . 26 3.1.5. Description フィールド . . . . . . . . . . . . . . 26 3.1.6. Deprecated フィールド . . . . . . . . . . . . . . . 28 3.1.7. Preferred-Value フィールド . . . . . . . . . . . . 28 3.1.8. Prefix フィールド . . . . . . . . . . . . . . . . . 31 3.1.9. Suppress-Script フィールド . . . . . . . . . . . . 32 3.1.10. Macrolanguage フィールド . . . . . . . . . . . . . 32 3.1.11. Scope フィールド . . . . . . . . . . . . . . . . . 33 3.1.12. Comments フィールド . . . . . . . . . . . . . . . . 34 3.2. 言語サブタグレビュアー . . . . . . . . . . . . . . . . 35 3.3. レジストリの保守 . . . . . . . . . . . . . . . . . . . 35 3.4. IANA レジストリエントリの安定性 . . . . . . . . . . . 36 3.5. サブタグの登録手続き . . . . . . . . . . . . . . . . . 41 3.6. 登録の可能性 . . . . . . . . . . . . . . . . . . . . . 46 3.7. 拡張および拡張レジストリ . . . . . . . . . . . . . . . 49 3.8. 言語サブタグレジストリの更新 . . . . . . . . . . . . 52 3.9. サブタグレジストリの適用可能性 . . . . . . . . . . . 52 4. 言語タグの形成と処理 . . . . . . . . . . . . . . . . . . . 53 4.1. 言語タグの選択 . . . . . . . . . . . . . . . . . . . . 53 4.1.1. 包含される言語へのタグ付け . . . . . . . . . . . 58 4.1.2. 拡張言語サブタグの使用 . . . . . . . . . . . . . 59 4.2. 言語タグの意味 . . . . . . . . . . . . . . . . . . . . 61 4.3. 言語のリスト . . . . . . . . . . . . . . . . . . . . . 63 4.4. 長さに関する考慮事項 . . . . . . . . . . . . . . . . . 63 4.4.1. 制限されたバッファサイズでの処理 . . . . . . . . 64 4.4.2. 言語タグの切り詰め . . . . . . . . . . . . . . . 65 4.5. 言語タグの正規化 . . . . . . . . . . . . . . . . . . . 66 Phillips & Davis ベスト・カレント・プラクティス [2ページ]
RFC 5646 言語タグ 2009年9月 4.6. 私的利用サブタグに関する考慮事項 . . . . . . . . . . . 68 5. IANA に関する考慮事項 . . . . . . . . . . . . . . . . . . . 69 5.1. 言語サブタグレジストリ . . . . . . . . . . . . . . . . 69 5.2. 拡張レジストリ . . . . . . . . . . . . . . . . . . . . 71 6. セキュリティに関する考慮事項 . . . . . . . . . . . . . . . 71 7. 文字集合に関する考慮事項 . . . . . . . . . . . . . . . . . 72 8. RFC 4646 からの変更点 . . . . . . . . . . . . . . . . . . . 73 9. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . 76 9.1. 規範的参考文献 . . . . . . . . . . . . . . . . . . . . 76 9.2. 参考情報 . . . . . . . . . . . . . . . . . . . . . . . 78 付録 A. 言語タグの例（参考） . . . . . . . . . . . . . . . . 80 付録 B. 登録フォームの例 . . . . . . . . . . . . . . . . . 82 付録 C. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . 83 1. はじめに 私たちの地球上では、過去から現在に至るまで、人間は数多くの 言語を使用してきた。情報を提示または要求するときに使用される 言語を識別したい理由は数多く存在する。 情報項目の言語またはユーザーの言語設定は、適切な処理を 適用できるようにするため、しばしば識別する必要がある。 たとえば、Web ブラウザーにおけるユーザーの言語設定を使用して、 Web ページを適切に選択できる。言語情報はまた、異なる言語の コンテンツの処理または理解を支援するツール（辞書など）を 選択するためにも使用できる。ある情報コンテンツで使用されている 特定の言語に関する知識は、スペルチェック、コンピューターによる 音声合成、点字への転写、高品質な印刷レンダリングなど、一部の 種類の処理にとって有用であるか、場合によっては必要となる。 使用されている言語を示す方法の一つは、情報コンテンツに 識別子または「タグ」を付けることである。これらのタグは、 情報コンテンツを選択するときにユーザーの設定を指定するため、 またはコンテンツおよび関連リソースの追加属性を示すためにも 使用できる。 言語タグは、コンテンツの追加的な言語属性を示すために使用される こともある。たとえば、文書またはリソースで使用されている方言、 文字体系、または正書法について具体的な情報を示すことで、 ユーザーが理解できる形式の情報を取得できるようになる場合があり、 また、与えられたコンテンツを適切な形式またはスタイルに処理または レンダリングするうえで重要となる場合がある。 この文書は、特定の識別子機構（言語タグ）と、タグを形成するために Phillips & Davis ベスト・カレント・プラクティス [3ページ]
RFC 5646 言語タグ 2009年9月 使用される値の登録機能を規定する。また、私的利用値および将来の 拡張のための機構も定義する。 この文書は [RFC4646]（これは [RFC3066] を廃止し、 さらにそれは [RFC1766] を置き換えた）を置き換える。この文書は [RFC4647] と合わせて BCP 47 を構成する。この文書の変更点の一覧については、 セクション 8 を参照されたい。 この文書におけるキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、 "SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、 [RFC2119] に記述されているとおりに解釈されるものとする。 2. 言語タグ 言語タグは、コミュニケーションの目的で、話し言葉、書き言葉、 手話、その他の方法で表現される言語を識別するために使用される。 これには構築言語および人工言語が含まれるが、プログラミング言語 など、主として人間同士のコミュニケーションを目的としていない 言語は除外される。 2.1. 構文 言語タグは、一つ以上の「サブタグ」のシーケンスから構成され、 各サブタグはタグ全体によって識別される言語の範囲をさらに 詳細化または限定する。各サブタグは英数字（文字と数字）の シーケンスであり、タグ内の他のサブタグとはハイフン ("-", [Unicode] U+002D) によって区別および分離される。 サブタグにはさまざまな種類があり、それぞれ長さ、タグ内での位置、 内容によって区別される。各サブタグの種類は、これらの特徴だけで 識別できる。このため、特定のサブタグ値が認識されない場合でも、 サブタグから一定の意味情報を抽出して割り当てることが可能である。 したがって、言語タグ処理系は、一般的な検索および照合処理を 実行するために、有効なタグまたはサブタグの一覧（すなわち IANA 言語サブタグレジストリの何らかの版のコピー）を保持する必要は ない。サブタグ構造から意味を推論するこの能力の唯一の例外は、 以下の 'regular' および 'irregular' 生成規則に列挙されている 旧来のタグである。これらのタグは [RFC3066] の下で登録されたものであり、 決して変更されない固定された一覧である。 ABNF [RFC5234] における言語タグの構文は次のとおりである。 Language-Tag = langtag ; 通常の言語タグ / privateuse ; 私的利用タグ / grandfathered ; 旧来のタグ Phillips & Davis ベスト・カレント・プラクティス [4ページ]
RFC 5646 言語タグ 2009年9月 langtag = language ["-" script] ["-" region] *("-" variant) *("-" extension) ["-" privateuse] language = 2*3ALPHA ; 最短の ISO 639 コード ["-" extlang] ; 後に続くことがある ; 拡張言語サブタグ / 4ALPHA ; または将来の使用のために予約 / 5*8ALPHA ; または登録済み言語サブタグ extlang = 3ALPHA ; 選択された ISO 639 コード *2("-" 3ALPHA) ; 永続的に予約 script = 4ALPHA ; ISO 15924 コード region = 2ALPHA ; ISO 3166-1 コード / 3DIGIT ; UN M.49 コード variant = 5*8alphanum ; 登録済みの変種 / (DIGIT 3alphanum) extension = singleton 1*("-" (2*8alphanum)) ; 単一の英数字 ; "x" は私的利用のために予約 singleton = DIGIT ; 0 - 9 / %x41-57 ; A - W / %x59-5A ; Y - Z / %x61-77 ; a - w / %x79-7A ; y - z privateuse = "x" 1*("-" (1*8alphanum)) grandfathered = irregular ; 登録された非冗長タグ / regular ; RFC 3066 時代に irregular = "en-GB-oed" ; irregular タグは / "i-ami" ; 'langtag' 生成規則に一致せず、 / "i-bnn" ; それ以外では / "i-default" ; 'well-formed' と / "i-enochian" ; 見なされない / "i-hak" ; これらのタグはすべて有効だが、 / "i-klingon" ; その大半はより新しい / "i-lux" ; サブタグまたはサブタグの / "i-mingo" ; 組み合わせを優先して非推奨 Phillips & Davis ベスト・カレント・プラクティス [5ページ]
RFC 5646 言語タグ 2009年9月 / "i-navajo" / "i-pwn" / "i-tao" / "i-tay" / "i-tsu" / "sgn-BE-FR" / "sgn-BE-NL" / "sgn-CH-DE" regular = "art-lojban" ; これらのタグは 'langtag' / "cel-gaulish" ; 生成規則に一致するが、そのサブタグは / "no-bok" ; 拡張言語サブタグでも / "no-nyn" ; 変種サブタグでもない。その意味は / "zh-guoyu" ; 登録によって定義され、 / "zh-hakka" ; これらはすべて、より新しい / "zh-min" ; サブタグまたはサブタグの / "zh-min-nan" ; シーケンスを優先して非推奨 / "zh-xiang" alphanum = (ALPHA / DIGIT) ; 文字と数字 図 1: 言語タグの ABNF 言語タグの例については、付録 A を参照されたい。 すべてのサブタグの最大長は 8 文字である。言語タグ内に空白を 含めることは許可されない。ABNF の 'variant' 生成規則には 微妙な点がある。数字で始まる変種の最小長は 4 文字である一方、 文字で始まるものの最小長は 5 文字である。 [RFC5234] はオクテットを参照しているが、この文書で説明される 言語タグは US-ASCII [ISO646] レパートリの文字シーケンスである。言語タグは、US-ASCII レパートリの該当部分を包含する限り、他の符号化方式を使用する 文書およびアプリケーションで使用してもよい。その一例は、 [Unicode] の UTF-16LE [RFC2781] 符号化を使用する XML 文書である。 2.1.1. 言語タグの書式 言語タグおよびそのサブタグは、私的利用と拡張を含め、常に 大文字と小文字を区別しないものとして扱わなければならない。 一部のサブタグには大文字化に関する慣例が存在するが、それらに 意味があると解釈してはならない。 したがって、タグ "mn-Cyrl-MN" は "MN-cYRL-mn" または "mN- cYrL-Mn"（あるいはその他の任意の組み合わせ）と区別されず、これらの各表記は Phillips & Davis ベスト・カレント・プラクティス [6ページ]
RFC 5646 言語タグ 2009年9月 同じ意味、すなわちモンゴルで使用されるキリル文字で記述された モンゴル語を表す。 ABNF 構文も大文字と小文字を区別しない。'A' から 'Z' の範囲の 大文字の US-ASCII 文字は常に等価と見なされ、'a' から 'z' の 範囲の対応する US-ASCII 小文字に直接対応付けられる。したがって、 タグ "I-AMI" は 'irregular' 生成規則内の値 "i-ami" と等価と 見なされる。 大文字と小文字の違いは言語タグ内で意味を持たないが、 言語タグの一貫した書式および表示はユーザーにとって有益である。 レジストリ内のサブタグの書式を、言語タグで使用する形式として 使用することが推奨される。この書式は一般に、サブタグの出典と なっている各種 ISO 規格における一般的な慣例に対応している。 これらの慣例には次のものが含まれる。 o [ISO639-1] は、言語コードを小文字で記述することを推奨している （'mn' モンゴル語）。 o [ISO15924] は、文字体系コードについて、先頭文字を大文字とし、 残りを小文字にすることを推奨している（'Cyrl' キリル文字）。 o [ISO3166-1] は、国コードを大文字で記述することを推奨している （'MN' モンゴル）。 実装は、レジストリへアクセスすることなく、次のようにこの書式を 再現できる。拡張および私的利用サブタグを含むすべてのサブタグでは、 二つの例外を除いて小文字を使用する。その例外は、タグの先頭にも singleton の後にも現れない 2 文字および 4 文字のサブタグである。 そのような 2 文字のサブタグはすべて大文字（タグ "en-CA-x-ca" や "sgn-BE-FR" など）とし、4 文字のサブタグはタイトルケース （タグ "az-Latn-x-latn" など）とする。 注: 特定のロケールにおける ASCII 文字の大文字・小文字変換は、 注意深く処理しない場合、非 ASCII の文字値を生成することがある。 Unicode Character Database のファイル "SpecialCasing.txt" [SpecialCasing] は、この問題を引き起こすことが知られている 特定のケースを定義している。特に、トルコ語および アゼルバイジャン語では、文字 'i' (U+0069) は U+0130 (LATIN CAPITAL LETTER I WITH DOT ABOVE) に大文字化される。 実装者は、サブタグの大文字・小文字変換によって言語タグでは 不正なこの値が生成されないよう、ロケールに依存しない 大文字・小文字変換処理を指定すべきである。たとえば、 地域サブタグ 'in' をトルコ語ロケールの規則で大文字化すると、 期待される 'IN' ではなく U+0130 U+004E のシーケンスが生成される。 Phillips & Davis ベスト・カレント・プラクティス [7ページ]
RFC 5646 言語タグ 2009年9月 2.2. 言語サブタグの出典と解釈 言語タグおよびそのサブタグの名前空間は、この文書の セクション 5 の規則に従って Internet Assigned Numbers Authority (IANA) によって管理される。IANA が管理する言語サブタグレジストリが 有効なサブタグの出典であり、このセクションで参照されるその他の 規格は、そのレジストリの元となる資料を提供する。 この文書で使用される用語は次のとおりである。 o 「Tag」は、"sr-Latn-RS" や "az-Arab-IR" などの完全な言語タグを 指す。この文書におけるタグの例は二重引用符で囲む （"en-US"）。 o 「Subtag」は、ハイフンで区切られたタグの特定部分を指す。 たとえば、タグ "zh-Hant-CN" におけるサブタグ 'zh'、'Hant'、 'CN' などである。この文書におけるサブタグの例は単一引用符で 囲む（'Hant'）。 o 「Code」は、外部規格で定義された値（この文書ではサブタグとして 使用される）を指す。たとえば、'Hant' は [ISO15924] の 文字体系コードであり、言語タグで使用する 'Hant' 文字体系 サブタグを定義するために使用された。この文書におけるコードの 例は単一引用符で囲む（'en'、'Hant'）。 言語タグは、各サブタグの種類が固有の長さおよび内容の制約を 持つように設計されている。これにより、サブタグ自体の内容が 認識されない場合でも、その種類を識別できる。そのため、 基礎となる規格または IANA レジストリの最新版を参照することなく タグを構文解析および処理でき、タグの構文解析に関連する例外処理も 簡素化される。 IANA レジストリ内の一部のサブタグは、基礎となる規格に由来しない。 これらはタグ内の特定位置にのみ現れることができる。すなわち、 主言語サブタグまたは変種サブタグとしてのみ使用できる。 私的利用および拡張サブタグのシーケンスは、サブタグシーケンスの 末尾に置かなければならず、この文書の他の箇所で定義される サブタグの間に挿入してはならない。これらのシーケンスは、 次のように予約された 1 文字のサブタグによって導入される。 o 1 文字のサブタグ 'x' は、私的利用サブタグのシーケンスを 導入する。私的利用サブタグの解釈は、 Phillips & Davis ベスト・カレント・プラクティス [8ページ]
RFC 5646 言語タグ 2009年9月 私的な合意によってのみ定義され、このセクションの規則、 またはこの文書で定義されるいかなる規格やレジストリによっても 定義されない。 o 1 文字のサブタグ 'i' は、"i-default" など一部の旧来のタグで 使用される。この場合、常に最初の位置に現れ、拡張と混同される ことはない。 o その他すべての 1 文字および 1 桁のサブタグは、 セクション 3.7 で説明する標準化された拡張サブタグシーケンスを 導入するために予約される。 2.2.1. 主言語サブタグ 主言語サブタグは言語タグの最初のサブタグであり、次の二つの 例外を除いて省略できない。 o 主サブタグとしての 1 文字のサブタグ 'x' は、その言語タグが、 意味が私的な合意によってのみ定義されるサブタグだけで 構成されていることを示す。たとえば、タグ "x-fr-CH" では、 サブタグ 'fr' および 'CH' は、それを行うための私的な合意が 存在しない限り、フランス語やスイスという国（または IANA レジストリ内のその他の値）を表さない。 セクション 4.6 を参照されたい。 o 1 文字のサブタグ 'i' は、"i-klingon" や "i-bnn" などの一部の 旧来のタグ（セクション 2.2.8 を参照）で使用される。（その他の 旧来のタグは、最初の位置に主言語サブタグを持つ。） 主言語サブタグには次の規則が適用される。 1. 2 文字の主言語サブタグは、規格 "ISO 639-1:2002, 言語名を表すためのコード -- 第1部: Alpha-2 コード" [ISO639-1] に記載された割り当て、またはその後 ISO 639-1 登録機関 (RA) または管轄する標準化機関によって行われた 割り当てに従って IANA レジストリに定義された。 2. IANA レジストリ内の 3 文字の主言語サブタグは、次に示す 追加の ISO 639 各部に記載された割り当て、またはその後 関連する ISO 639 登録機関または管轄する標準化機関によって 行われた割り当てに従って定義された。 A. "ISO 639-2:1998 - 言語名を表すためのコード -- 第2部: Alpha-3 コード - 第1版" [ISO639-2] Phillips & Davis ベスト・カレント・プラクティス [9ページ]
RFC 5646 言語タグ 2009年9月 B. "ISO 639-3:2007 - 言語名を表すためのコード -- 第3部: 言語を包括的に網羅するための Alpha-3 コード" [ISO639-3] C. "ISO 639-5:2008 - 言語名を表すためのコード -- 第5部: 言語族および言語グループのための Alpha-3 コード" [ISO639-5] 3. 'qaa' から 'qtz' の範囲のサブタグは、言語タグにおける 私的利用のために予約されている。これらのサブタグは、 ISO 639-2 が私的利用のために予約しているコードに対応する。 これらのコードは、'x-' に続く私的利用サブタグを使用する 代わりに、未登録の主言語サブタグとして使用してもよい。 私的利用サブタグの詳細については セクション 4.6 を参照されたい。 4. 4 文字の言語サブタグは、将来の標準化の可能性のために 予約されている。 5. IANA レジストリ内にある長さ 5 文字から 8 文字の言語サブタグは、 セクション 3.5 の登録手続きを通じて定義されたものであり、 主言語サブタグを形成するために使用してもよい。このような 登録に含まれ得るものの例として、旧来の IANA 登録 "i-enochian" がある。サブタグ 'enochian' は、IANA レジストリに 主言語サブタグとして登録できる（ISO 639 がこの言語を先に 登録しないことを前提とする）。これにより、"enochian-AQ" や "enochian-Latn" といったタグが有効になる。 この文書が作成された時点では、この種類のサブタグの例は 存在しなかった。この種類の将来の登録は推奨されない。 新たに提案される主言語を登録する試みは、まず ISO 639 登録機関に対して行わなければならない。ISO 639 登録機関に 拒否された提案は、主言語サブタグの基準を満たす可能性が低く、 したがって登録される可能性も低い。 6. この文書の改訂または更新による場合を除き、主サブタグに その他の値を割り当ててはならない。 ある言語に ISO 639-1 の 2 文字コードと 3 文字コード （ISO 639-2、ISO 639-3、または ISO 639-5 によって割り当てられた） の両方がある場合、IANA レジストリには ISO 639-1 の 2 文字コード だけが定義される。 ある言語に ISO 639-1 の 2 文字コードがなく、その言語について ISO 639-2/T (Terminology) コードと ISO 639-2/B (Bibliographic) コードが異なる場合、Terminology コードだけが IANA レジストリに 定義される。この文書が作成された時点では、両方の種類の 3 文字コードを持つすべての言語には、 Phillips & Davis ベスト・カレント・プラクティス [10ページ]
RFC 5646 言語タグ 2009年9月 2 文字コードも割り当てられていた。この種の割り当ては今後 発生しないと予想される。 タグの正規形が不安定になることを避けるため、ISO 639-2 または ISO 639-3 のいずれかに 3 文字コードがすでに含まれている言語に ISO 639-1 の 2 文字コードが追加された場合、その 2 文字コードを 登録してはならない。セクション 3.4 を参照されたい。 たとえば、現在 2 文字コードを持たないハワイ語に、あるコンテンツが 'haw' というタグを付けられていた場合、その後 ISO 639-1 が ハワイ語に 2 文字コードを割り当てたとしても、そのタグを 変更する必要はない。 このようなバージョン管理およびサブタグ選択上の問題 （RFC 1766 から RFC 3066 への移行時に経験されたもの）を回避し、 またこの文書によって定義されるサブタグの正規性を確保するため、 ISO 639 Registration Authority Joint Advisory Committee (ISO 639/RA-JAC) は [iso639.prin] に次の声明を含めている。 "ISO 639-1 の凍結時点ですでに ISO 639-2 に含まれている言語 コードは、その後 ISO 639-1 に追加してはならない。これは、 その言語の alpha-2 コードが利用できない場合、インターネット アプリケーションでは alpha-3 コードを使用するようユーザーに 指示されているため、長期にわたる使用の一貫性を確保するためである。" 2.2.2. 拡張言語サブタグ 拡張言語サブタグは、さまざまな歴史的および互換性上の理由から、 既存の主言語サブタグと密接に関連付けられている、またはそれを 使用してタグ付けされている、特別に選択された特定の言語を 識別するために使用される。拡張言語サブタグは、言語タグを 形成するとき、常にそれを包含する主言語サブタグ （レジストリ内の 'Prefix' フィールドによって示される）とともに 使用される。レジストリ内に拡張言語サブタグを持つすべての言語は、 同一の主言語サブタグレコードもレジストリ内に持つ。言語タグを 形成する際には、この主言語サブタグを使用することが推奨される。 拡張言語サブタグには次の規則が適用される。 1. 拡張言語サブタグは、3 文字のサブタグだけで構成される。 レジストリで定義されたすべての拡張言語サブタグレコードは、 [ISO639-3] に記載された割り当てに従って定義された。 [ISO639-5] で定義されるような言語の集合およびグループは、 拡張言語サブタグから明示的に除外される。 Phillips & Davis ベスト・カレント・プラクティス [11ページ]
RFC 5646 言語タグ 2009年9月 2. 拡張言語サブタグレコードには、その拡張言語サブタグに適切な サブタグまたはサブタグシーケンスを示す 'Prefix' フィールドを 正確に一つ含めなければならない。 3. 拡張言語サブタグレコードには 'Preferred-Value' を 含めなければならない。'Preferred-Value' と 'Subtag' フィールドは同一でなければならない。 4. ABNF の生成規則 'extlang' は言語タグ内に最大三つの拡張言語 タグを許可しているが、拡張言語サブタグの 'Prefix' に別の 拡張言語サブタグを含めてはならない。すなわち、言語タグ内の 第2および第3の拡張言語サブタグ位置は恒久的に予約されており、 それらの位置にサブタグを含むタグは現在も将来も常に無効である。 たとえば、マクロ言語である中国語 ('zh') は多数の言語を包含する。 互換性上の理由から、これらの各言語はレジストリ内に主言語サブタグと 拡張言語サブタグの両方を持つ。選択したいくつかの例には、 贛語 ('gan')、広東語 ('yue')、官話 ('cmn') がある。これらは それぞれマクロ言語 'zh'（中国語）に包含される。そのため、 各レジストリレコードには接頭辞 "zh" がある。したがって、 贛語は "zh-gan" または "gan" で始まるタグで、広東語は "yue" または "zh-yue" で始まるタグで、官話は "zh-cmn" または "cmn" で表される。言語サブタグ 'zh' は、特定されていない 中国語の一種としてリソースを示すために、拡張言語サブタグなしで 引き続き使用できるが、拡張言語形式 ("zh-gan", "zh-yue", "zh-cmn") よりも主言語サブタグ ('gan', 'yue', 'cmn') の使用が推奨される。 2.2.3. 文字体系サブタグ 文字体系サブタグは、言語またはその方言の書記形式を区別する 文字体系または表記体系の違いを示すために使用される。 文字体系サブタグには次の規則が適用される。 1. 文字体系サブタグは、主言語および拡張言語サブタグの後に 置かなければならず、その他すべての種類のサブタグより前に 置かなければならない。 2. 文字体系サブタグは 4 文字で構成され、 [ISO15924]（「情報およびドキュメンテーション -- 文字体系名を表すためのコード」）に記載された割り当て、 またはその後 ISO 15924 登録機関または管轄する標準化機関に よって割り当てられたものに従って定義された。ISO 15924 に よって割り当てられたコードだけが登録対象として検討される。 Phillips & Davis ベスト・カレント・プラクティス [12ページ]
RFC 5646 言語タグ 2009年9月 3. 文字体系サブタグ 'Qaaa' から 'Qabx' は、言語タグにおける 私的利用のために予約されている。これらのサブタグは、 ISO 15924 が私的利用のために予約しているコードに対応する。 これらのコードは、未登録の文字体系値に使用してもよい。 私的利用サブタグの詳細については セクション 4.6 を参照されたい。 4. 言語タグ内の文字体系サブタグは最大一つでなければならず、 タグに区別上の価値を何も追加しない場合、またはサブタグ レジストリ内の主言語もしくは拡張言語サブタグのレコードに、 該当する文字体系サブタグを列挙した 'Suppress-Script' フィールドが含まれている場合には、文字体系サブタグを 省略すべきである。 たとえば、"sr-Latn" はラテン文字で記述されたセルビア語を表す。 2.2.4. 地域サブタグ 地域サブタグは、特定の国、領土、または地域に関連する、 あるいはそれに適した言語上の変異を示すために使用される。 通常、地域サブタグは、地域方言や用法、地域固有の綴りの慣例などの 変異を示すために使用される。また、たとえばラテンアメリカ全域で 有用となるよう調整されたスペイン語コンテンツのように、 地域全体での使用に適した方法でコンテンツが表現されていることを 示すためにも使用できる。 地域サブタグには次の規則が適用される。 1. 地域サブタグは、主言語、拡張言語、または文字体系サブタグの 後に置かなければならず、その他すべての種類のサブタグより 前に置かなければならない。 2. 2 文字の地域サブタグは、 [ISO3166-1]（「国およびその下位区分の名称を表すための コード -- 第1部: 国コード」）に記載された割り当てに従い、 alpha-2 国コードの一覧、またはその後 ISO 3166-1 保守機関 もしくは管轄する標準化機関によって行われた割り当てを使用して 定義された。さらに、ISO 3166-1 で（「割り当て済み」ではなく） 「例外的に予約」とされているコードも、割り当て済みコード 'GB' と完全に同義である 'UK' を除き、レジストリに定義された。 3. 地域サブタグ 'AA'、'QM'-'QZ'、'XA'-'XZ'、および 'ZZ' は、 言語タグにおける私的利用のために予約されている。これらの サブタグは ISO 3166 が私的利用のために予約しているコードに 対応する。これらのコードは、私的利用サブタグシーケンスを 使用する代わりに、私的利用の地域サブタグとして使用してもよい。 私的利用サブタグの詳細については セクション 4.6 を参照されたい。 Phillips & Davis ベスト・カレント・プラクティス [13ページ]
RFC 5646 言語タグ 2009年9月 4. 3 文字の地域サブタグは数字だけで構成され、UN Standard Country or Area Codes for Statistical Use [UN_M.49] に 記載された割り当て、またはその後管轄する標準化機関によって 行われた割り当てに従って定義された。UN M.49 のすべてのコードが IANA レジストリに定義されているわけではない。どのコードを 有効なサブタグとしてレジストリに登録するかは、次の規則によって 定義される。 A. 「マクロ地理的（大陸）」地域またはその下位地域に 割り当てられた UN 数値コードは、レジストリに登録しなければ ならない。これらのコードには割り当て済みの ISO 3166-1 alpha-2 コードが関連付けられておらず、通常は複数の国家、 州、省、または領土を含む超国家的地域を表す。 B. 「経済的グループ」または「その他のグループ」に対する UN 数値コードは IANA レジストリに登録してはならず、 言語タグを形成するために使用してはならない。 C. ISO 3166-1 が、以前ある国または地域に使用されていた コードを別の国または地域に再割り当てし、そのコードが すでにレジストリに存在する場合、その国または地域に対する UN 数値コードを セクション 3.4 に記載されているとおり レジストリに登録しなければならず、そのコードが定義する 国または地域を表す言語タグの形成には、再利用された ISO 3166-1 コードではなく、その UN 数値コードを使用しなければならない。 D. レジストリ内に関連付けられた ISO 3166-1 alpha-2 コードを 持つ国または地域の UN 数値コードは、レジストリに登録しては ならず、言語タグを形成するために使用してはならない。 レジストリ内の ISO 3166 ベースのサブタグは、実際に対象となる UN M.49 コードと関連付けられていなければならないことに注意されたい。 E. 歴史的理由により、この文書が採用された時点では登録されて おらず、当時対応する ISO 3166-1 コードも存在しなかった UN 数値コード 830（チャネル諸島）は、それと正確に同じ意味を 持つ ISO 3166-1 コードが以前に登録されていないことを条件に、 セクション 3.5 に記載された手続きによって IANA レジストリに 登録してもよい。 F. 関連する ISO 3166-1 alpha-2 コードを持たないその他すべての 国または地域の UN 数値コードは、レジストリに登録しては ならず、言語タグを形成するために使用してはならない。 これらのコードの詳細については セクション 3.4 を参照されたい。 Phillips & Davis ベスト・カレント・プラクティス [14ページ]
RFC 5646 言語タグ 2009年9月 5. UN 文書の 付録 X にある英数字コードはレジストリに 登録してはならず、言語タグを形成するために使用してはならない。 （この文書が作成された時点では、これらの値は ISO 3166-1 alpha-2 コードと一致していた。） 6. 言語タグ内の地域サブタグは最大一つでなければならず、 タグに区別上の価値を何も追加しない場合などには、 地域サブタグを省略してもよい。 例: "de-AT" は、オーストリア ('AT') で使用されるドイツ語 ('de') を表す。 "sr-Latn-RS" は、セルビア ('RS') で使用される、ラテン文字 ('Latn') で記述されたセルビア語 ('sr') を表す。 "es-419" は、国連が定義するラテンアメリカおよびカリブ地域 ('419') に適したスペイン語 ('es') を表す。 2.2.5. 変種サブタグ 変種サブタグは、利用可能な他のサブタグでは表現されない、 言語またはその方言を定義する追加の広く認識された変異を 示すために使用される。変種サブタグには次の規則が適用される。 1. 変種サブタグは、主言語、拡張言語、文字体系、または地域 サブタグの後に置かなければならず、拡張または私的利用 サブタグシーケンスより前に置かなければならない。 2. 変種サブタグ全体は、特定の外部規格とは関連付けられていない。 レジストリ内の変種サブタグの意味は、セクション 3.5 で定義する 登録手続きの過程で定義される。特定の変種サブタグが何らかの 外部規格と関連付けられる場合があることに注意されたい。 ただし、規格との関連付けは登録に必須ではない。 3. 言語タグを形成するために複数の変種を使用してもよい。 4. 変種サブタグは、言語タグの形成に使用する前に、 この文書の セクション 3.5 の規則に従って IANA に登録しなければならない。 変種を他の種類のサブタグと区別するため、登録は次の長さおよび 内容の制約を満たさなければならない。 1. 文字 (a-z, A-Z) で始まる変種サブタグは、 少なくとも 5 文字でなければならない。 Phillips & Davis ベスト・カレント・プラクティス [15ページ]
RFC 5646 言語タグ 2009年9月 2. 数字 (0-9) で始まる変種サブタグは、少なくとも 4 文字でなければならない。 5. 同じ変種サブタグを一つの言語タグ内で複数回使用してはならない。 * たとえば、タグ "de-DE-1901-1901" は有効ではない。 言語サブタグレジストリ内の変種サブタグレコードには、一つ以上の 'Prefix'（セクション 3.1.8）フィールドを含めてもよい。各 'Prefix' は、 その変種を使用して言語タグを形成するときに適したサブタグの シーケンス（必要に応じて他のサブタグとともに）を示す。 同じ prefix を共有する変種の多くは相互排他的である。 たとえば、ドイツ語の正書法上の変種 '1996' と '1901' は、 異なる綴り改革の年代を表すため、同じタグで使用すべきではない。 別の変種と意味のある形で組み合わせて使用できる変種は、 その別の変種を列挙する 'Prefix' フィールドをレジストリレコードに 含めるべきである。たとえば、'1996' とともに使用することに 意味がある別のドイツ語変種 'example' が作成された場合、 'example' は "de" と "de-1996" という二つの 'Prefix' フィールドを含めるべきである。 例: "sl-nedis" はスロベニア語のナティゾーネ方言またはナディジャ方言を表す。 "de-CH-1996" は、スイスで使用され、1996 年に始まった 綴り改革を用いて記述されたドイツ語を表す。 2.2.6. 拡張サブタグ 拡張は、さまざまなアプリケーションで使用するために言語タグを 拡張する機構を提供する。これは、言語または言語タグと一般に 関連して使用されるが、言語識別そのものの一部ではない情報を 識別することを目的としている。セクション 3.7 を参照されたい。 拡張には次の規則が適用される。 1. 拡張は、少なくとも主言語サブタグの後に置かなければならない。 すなわち、言語タグを拡張から始めることはできない。 拡張は言語タグを拡張するものであり、それを上書きしたり 置き換えたりするものではない。たとえば、"a-value" は 整形式の言語タグではないが、"de-a-value" は整形式である。 拡張は、完全に私的利用であるタグ（すなわち "x-" で始まるタグ） では使用できないことに注意されたい。 Phillips & Davis ベスト・カレント・プラクティス [16ページ]
RFC 5646 言語タグ 2009年9月 2. 拡張サブタグは、この文書で定義される他のサブタグとは、 1 文字のサブタグ（"singleton" と呼ばれる）によって区切られる。 singleton は、セクション 3.7 で説明する機構を通じて登録機関に 割り当てられたものでなければならず、私的利用サブタグ シーケンスのために予約されている文字 'x' であってはならない。 3. 各 singleton サブタグは、各タグ内で（私的利用サブタグとしての 場合を除き）最大一回だけ現れなければならない。すなわち、 singleton サブタグを繰り返してはならない。たとえば、 タグ "en-a-bbb-a-ccc" は、サブタグ 'a' が二回現れるため無効である。 タグ "en-a-bbb-x-a-ccc" は、singleton 'a' の二回目の出現が 私的利用シーケンス内にあるため有効であることに注意されたい。 4. 拡張サブタグは、その singleton 接頭辞を定義する文書で設定された すべての要件、および管理機関によって提示されるすべての要件を 満たさなければならない。これらのサブタグのレジストリが 存在しない場合があり、検証を行う処理系に拡張の検証は 要求されないことに注意されたい。 5. 各拡張サブタグは 2 文字から 8 文字まででなければならず、 文字または数字だけで構成し、各サブタグは一つの '-' で 区切らなければならない。拡張では（その他の言語サブタグと同様に） 大文字と小文字の違いは無視され、この種類の正規化された サブタグは小文字になることが想定される。 6. 各 singleton の後には少なくとも一つの拡張サブタグが 続かなければならない。たとえば、タグ "tlh-a-b-foo" は、 最初の singleton 'a' の直後に別の singleton 'b' が続くため 無効である。 7. 拡張サブタグは、タグ内のすべての主言語、拡張言語、文字体系、 地域、および変種サブタグの後に置かなければならず、 すべての私的利用サブタグシーケンスより前に置かなければならない。 8. singleton の後から次の singleton の前までにあるすべての サブタグは、その拡張の一部である。例: タグ "fr-a-Latn" において、 サブタグ 'Latn' は IANA 言語サブタグレジストリで定義された 文字体系サブタグ 'Latn' を表さない。その意味は拡張 'a' によって 定義される。 9. 一つのタグに複数の拡張が現れる場合、そのタグは セクション 4.5 に記載されているように、各拡張シーケンスを 大文字と小文字を区別しない ASCII 順に並べることによって 正規化すべきである。 たとえば、singleton 'r' 用の拡張が定義され、その拡張が示された サブタグを定義した場合、次のタグが有効な例となる: "en-Latn-GB-boont-r-extended-sequence-x-private"。 Phillips & Davis ベスト・カレント・プラクティス [17ページ]
RFC 5646 言語タグ 2009年9月 2.2.7. 私的利用サブタグ 私的利用サブタグは、特定の文脈で重要となる言語上の区別を 私的な合意によって示すために使用される。私的利用サブタグには 次の規則が適用される。 1. 私的利用サブタグは、この文書で定義されるその他のサブタグとは、 予約された 1 文字のサブタグ 'x' によって区切られる。 2. 私的利用サブタグは、すべてのサブタグについて ABNF で定義された 書式および内容の制約に従わなければならない。すなわち、 文字と数字だけで構成され、長さが 8 文字を超えてはならない。 3. 私的利用サブタグは、タグ内のすべての主言語、拡張言語、 文字体系、地域、変種、および拡張サブタグの後に 置かなければならない。別の言い方をすれば、singleton 'x' の 後にあるすべてのサブタグは私的利用と見なさなければならない。 例: タグ "en-x-US" のサブタグ 'US' は私的利用サブタグである。 4. タグは私的利用サブタグだけで構成してもよい。 5. 私的利用サブタグについて出典は定義されない。私的利用サブタグの 使用は私的な合意だけに基づく。 6. 代替手段が存在する場合、または一般的な交換用途では、 私的利用サブタグは推奨されない。私的利用サブタグの選択の 詳細については セクション 4.6 を参照されたい。 たとえば、ある研究者のグループが中世ギリシャ語の文書を研究している とする。そのグループは、文書内の異なる文体を識別するために、 何らかの私的利用サブタグ群を使用することに合意するかもしれない。 たとえば、「共通」スタイルの文書には 'el-x-koine' を使用し、 アッティカ様式を模倣したその他の文書には 'el-x-attic' を 使用することが考えられる。これらのサブタグは外部の処理や システムによって認識されないが、そのグループ内で研究のために 各種文書を分類する際には有用である可能性がある。 レジストリには、ISO 639、ISO 15924、または ISO 3166 が私的利用の ために予約したコードに由来するサブタグも存在する。これらを、 サブタグ 'x' に続く私的利用サブタグシーケンスと混同してはならない。 セクション 4.6 を参照されたい。 2.2.8. 旧来および冗長な登録 RFC 4646 より前は、言語タグ全体が RFC 1766 および／または RFC 3066 の規則に従って登録されていた。これらの登録済みタグは すべて、言語タグとして引き続き有効である。 Phillips & Davis ベスト・カレント・プラクティス [18ページ]
RFC 5646 言語タグ 2009年9月 これらの登録済みタグの多くは、RFC 4646 またはこの文書の登場によって 冗長となった。冗長タグとは、その個々のサブタグが同じ意味で レジストリ内に現れる旧来の登録である。たとえば、タグ "zh-Hant" （繁体字中国語）は、現在ではサブタグ 'zh'（中国語）と 'Hant'（漢字の繁体字変種）から構成できる。これらの冗長タグは、 主として歴史的資料として、レジストリ内で 'redundant' 型の レコードとして維持される。 以前に登録された残りのタグは「旧来」とされる。 これらのタグは 'regular' と 'irregular' の二つのグループに 分類される。 図 1 の 'langtag' 生成規則に（見かけ上）一致する旧来のタグは、 'regular' な旧来のタグと見なされる。これらのタグには、 個別にはレジストリに存在しない、または存在しても異なる意味を持つ 一つ以上のサブタグが含まれる。各タグは全体として一つの言語または 言語の集合を表す。 ABNF の 'langtag' 生成規則に一致せず、それ以外では無効となる 旧来のタグは、'irregular' な旧来のタグと見なされる。"en-GB" の 変種である "en-GB-oed" を除き、それぞれが全体として一つの言語を 表す。 旧来のタグの多くは、その後新しいサブタグが追加されたことによって 置き換えられている。置き換えられた各レコードには、その値を表す 言語タグを形成するために使用すべき 'Preferred-Value' フィールドが 含まれる。たとえば、タグ "art-lojban" は主言語サブタグ 'jbo' に よって置き換えられている。 2.2.9. 適合性のクラス 実装は、この文書で説明される規則および慣行に関する自身の能力を 記述する必要がある場合がある。タグはさまざまな方法で確認または 検証できるが、ここでは特に二つのタグ適合性クラスを正式に定義する。 タグが ABNF（セクション 2.1）に適合する場合、そのタグは "well-formed" と見なされる。言語タグは構文上は整形式であっても、 内容上は有効でない場合がある。ただし、言語タグを伴う多くの処理は、 サブタグの意味または有効性について何も知らなくても適切に機能する。 タグが次の条件を満たす場合、そのタグは "valid" と見なされる。 o タグが整形式である。 Phillips & Davis ベスト・カレント・プラクティス [19ページ]
RFC 5646 言語タグ 2009年9月 o タグが旧来のタグの一覧に含まれているか、またはそのすべての 主言語、拡張言語、文字体系、地域、および変種サブタグが、 特定のレジストリ日付時点の IANA 言語サブタグレジストリに 存在する。 o 重複する変種サブタグがない。 o 重複する singleton（拡張）サブタグがない。 タグの有効性は、そのタグの検証に使用するレジストリの日付に 依存することに注意されたい。より新しいレジストリのコピーには、 古い版には存在しないサブタグが含まれている場合がある。 タグが上記の "valid" の基準を満たし、さらに次の条件を満たす場合、 そのタグは特定の拡張（セクション 3.7）について（特定の版、 改訂、および日付時点で）有効と見なされる。 タグの拡張部分で使用される各サブタグが、その拡張に従って 有効である。 古い仕様または言語タグ実装では、[RFC3066] を参照している場合がある。 同文書では、より広範なタグが整形式と見なされていた。 RFC 3066 の下で使用するために有効であったタグはすべて、 この文書の構文の下でも整形式かつ有効である。以前の定義では 整形式であったものの、現在はそうではないのは、無効または 不正なタグだけである。RFC 3066 における言語タグ構文は 次のとおりであった。 obs-language-tag = primary-subtag *( "-" subtag ) primary-subtag = 1*8ALPHA subtag = 1*8(ALPHA / DIGIT) 図 2: RFC 3066 の言語タグ構文 私的利用に指定されたサブタグ、および 'x' サブタグによって 導入される私的利用シーケンスは、割り当て済みのサブタグがなく、 登録も適切な選択肢ではない場合に利用できる。たとえば、 未定義の地域を示すために、私的利用の ISO 3166-1 コード範囲の 一つである 'QQ' を用いて "no-QQ" のようなタグを使用することが 考えられる。ユーザーは、私的利用シーケンス内 （タグ "en-x-personal" のサブタグ 'personal' など）を除き、 レジストリに存在しないサブタグを使用する言語タグを割り当てては ならない。そのようなタグは有効でないだけでなく、将来行われる 可能性のある割り当てまたは登録と衝突する危険もある。 特に注意されたい。この文書に現れる 'Language-Tag' 生成規則は、 [RFC4646] のものと機能的に等価であるが、 Phillips & Davis ベスト・カレント・プラクティス [20ページ]
RFC 5646 言語タグ 2009年9月 旧来の 'grandfathered' 生成規則から生じる整形式性に関する特定の エラーを防ぐために変更されている。 3. レジストリの形式と保守 IANA 言語サブタグレジストリ（「レジストリ」）には、言語タグで 有効なすべてのサブタグの包括的な一覧が含まれている。 これにより、実装者は言語タグを検証するための単純で信頼できる 方法を利用できる。レジストリは、拡張サブタグを除き、この文書、 またはその改訂版もしくは後継文書の規定に基づいて言語タグに 現れるすべてのサブタグを検証できるように保守される。 さらに、各種サブタグの意味は明確であり、長期にわたって安定する。 （もちろん、私的利用サブタグの意味はレジストリによって 定義されない。） このセクションでは、レジストリと、それに関連する保守および 更新手続き、ならびに言語タグの拡張のためのレジストリ （セクション 3.7）を定義する。 3.1. IANA 言語サブタグレジストリの形式 IANA 言語サブタグレジストリは、このセクションで説明する形式の 機械可読ファイルと、セクション 3.5 に記載された手続きに従って 承認された登録フォームのコピーから構成される。 RFC 3066 に由来する旧来および冗長なタグの既存の登録フォームは、 廃止された RFC 3066 レジストリの一部として維持されている。[RFC4645] または [RFC5645] のいずれかによってレジストリに追加されたサブタグには、 個別の登録フォームはない（したがって、これらの追加について フォームは保存されていない）。 3.1.1. ファイル形式 レジストリは [Unicode] テキストファイルであり、 "record-jar"（[record-jar] で説明されている）に基づく形式の 一連のレコードから構成される。各レコードはさらに、さまざまな サブタグおよびタグを記述する一連のフィールドから構成される。 実際のレジストリファイルは UTF-8 [RFC3629] 文字エンコーディングを 使用して符号化される。 各フィールドは、一つの論理的な文字行と見なすことができる。 各フィールドには "field-name" と "field-body" が含まれる。 これらは "field-separator" によって区切られる。field-separator は COLON 文字 (U+003A) と、その周囲にある任意の空白である。 各フィールドは改行シーケンス CRLF で終了する。各フィールドの テキストは Unicode 正規化形式 C (NFC) でなければならない。 Phillips & Davis ベスト・カレント・プラクティス [21ページ]
RFC 5646 言語タグ 2009年9月 フィールドの集合が一つの "record" を形成する。レコードは、 シーケンス "%%" (U+0025 U+0025) だけを含む行によって区切られる。 フィールドは論理的には一行のテキストであるが、ファイル形式に おける各テキスト行の長さは 72 バイトに制限される。これに対応する ため、field-body は複数行の表現に分割できる。これは "folding" と呼ばれる。folding は、通常の行折り返しの慣例に従って行われる。 通常は空白の境界で行われるが、言語が単語間に空白を使用しない場合 など、値に空白が含まれない場合は他の文字間で行われることもある。 いずれの場合も、複数バイト UTF-8 シーケンスの内部または結合文字 シーケンスの途中で改行してはならない。詳細については [UAX14] を参照されたい。 ファイル形式は Unicode 文字集合を使用し、ファイル自体は UTF-8 エンコーディングを使用して符号化されるが、特定フィールドの説明で 別途示されない限り（セクション 3.1.2）、フィールドは US-ASCII [ISO646] レパートリの印字可能文字に制限される。 レジストリの形式は、次の ABNF [RFC5234] によって記述される。文字番号（コードポイント）は Unicode から取得され、ABNF 生成規則の終端記号はバイトではなく文字として 表される。 registry = record *("%%" CRLF record) record = 1*field field = ( field-name field-sep field-body CRLF ) field-name = (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)] field-sep = *SP ":" *SP field-body = *([[*SP CRLF] 1*SP] 1*CHARS) CHARS = (%x21-10FFFF) ; Unicode コードポイント 図 3: レジストリ形式の ABNF field-body 内のシーケンス '..' (U+002E U+002E) は値の範囲を示す。 このような範囲は、明示的に記載された値を含め、その範囲内で アルファベット順または数値順に並ぶ同じ長さのすべてのサブタグを 表す。たとえば、'a..c' は値 'a'、'b'、'c' を示し、'11..13' は 値 '11'、'12'、'13' を示す。 field-body に日付値を含むすべてのフィールドでは、[RFC3339] で 規定される "full-date" 形式を使用する。たとえば、"2004-06-28" は グレゴリオ暦の 2004 年 6 月 28 日を表す。 Phillips & Davis ベスト・カレント・プラクティス [22ページ]
RFC 5646 言語タグ 2009年9月 3.1.2. レコードおよびフィールドの定義 レジストリには "File-Date"、"Subtag"、"Tag" の三種類の レコードがある。 レジストリの最初のレコードは常に "File-Date" レコードである。 このレコードはファイル内に一度だけ現れ、field-name が "File-Date" である単一のフィールドを含む。このレコードの field-body には日付（セクション 5.1 を参照）が含まれるため、 レジストリの異なる版を容易に識別できる。 File-Date: 2004-06-28 %% 図 4: File-Date レコードの例 それ以降のレコードは複数のフィールドを含み、サブタグまたはタグに 関する情報を表す。両種類のレコードは同一の構造を持つが、 "Subtag" レコードには field-name が "Subtag" のフィールドが 含まれ、一方、当然ながら "Tag" レコードには field-name が "Tag" のフィールドが含まれる。field-name は、'Description'、 'Comments'、'Prefix' フィールドを除き、各レコードに複数回 現れてはならない。 各レコードには、次の各フィールドを少なくとも一つ含めなければ ならない。 o 'Type' * Type の field-body は、次の文字列のいずれかでなければならない: "language"、"extlang"、"script"、"region"、"variant"、 "grandfathered"、"redundant"。これはタグまたはサブタグの 種類を示す。 o 'Subtag' または 'Tag' * Subtag の field-body には、定義されるサブタグが含まれる。 このフィールドは、'Type' が "language"、"extlang"、 "script"、"region"、または "variant" のいずれかである すべてのレコードに現れなければならない。 * Tag の field-body には、完全な言語タグが含まれる。 このフィールドは、'Type' が "grandfathered" または "redundant" のすべてのレコードに現れなければならない。 'Type' が "grandfathered" の場合、'Tag' の field-body は セクション 2.1 にある 'regular' または 'irregular' の いずれかの生成規則に列挙されたタグの一つとなる。 Phillips & Davis ベスト・カレント・プラクティス [23ページ]
RFC 5646 言語タグ 2009年9月 o 'Description' * Description の field-body には、サブタグまたはタグの 非規範的な説明が含まれる。 o 'Added' * Added の field-body には、レコードが登録された日付、 または旧来もしくは冗長なタグの場合には、対応するタグが [RFC1766] または [RFC3066] の規則に基づいて登録された 日付が含まれる。 各レコードには、さらに次のフィールドを含めてもよい。 o 'Deprecated' * Deprecated の field-body には、そのレコードが非推奨とされた 日付が含まれる。場合によっては、この値が同じレコードの 'Added' フィールドの値より前の日付になる。すなわち、 非推奨となった日付が、そのレコードがレジストリに追加された 日付よりも前である。 o 'Preferred-Value' * Preferred-Value の field-body には、このレコードの値から、 その代わりとして推奨される現代的な同等値への正規対応付けが 含まれる。'Type' フィールドの値に応じて、この値は異なる 形式を取ることができる。 + 'language' 型のフィールドでは、'Preferred-Value' に、 言語タグを形成するときに推奨される主言語サブタグが 含まれる。 + 'script'、'region'、または 'variant' 型のフィールドでは、 'Preferred-Value' に、言語タグを形成するときに推奨される 同じ種類のサブタグが含まれる。 + 'extlang'、'grandfathered'、または 'redundant' 型の フィールドでは、'Preferred-Value' に、言語タグを形成する ために推奨される「拡張言語範囲」[RFC4647] が含まれる。 すなわち、推奨される言語タグには 'Preferred-Value' に 現れる各サブタグが順に含まれる。この文書の他の箇所で 説明されているように、言語タグには追加のフィールドを 含めることができる。たとえば、旧来のタグ "zh-min- Phillips & Davis ベスト・カレント・プラクティス [24ページ]
RFC 5646 言語タグ 2009年9月 nan"（閩南語）の置換は "nan" であり、これは "nan-Hant" や "nan-TW" といったタグの基礎として使用できる （"zh-nan-Hant" や "zh-nan-TW" のような拡張言語サブタグ 形式も使用できることに注意されたい）。 o 'Prefix' * Prefix の field-body には、このレコードのサブタグに対する 可能な接頭辞の一つとして推奨される有効な言語タグが含まれる。 このフィールドは、'Type' の field-body が 'extlang' または 'variant' のレコードに現れてもよい（その他のレコード型には 現れてはならない）。 o 'Suppress-Script' * Suppress-Script の field-body には、関連付けられた主言語 または拡張言語サブタグとともに言語タグを形成するために 使用すべきではない文字体系サブタグが含まれる。 このフィールドは、'Type' の field-body が 'language' または 'extlang' であるレコードにのみ現れなければならない。 セクション 4.1 を参照されたい。 o 'Macrolanguage' * Macrolanguage の field-body には、ISO 639 によってこの言語 サブタグを包含する「マクロ言語」として定義された主言語 サブタグが含まれる。このフィールドは、'Type' の field-body が 'language' または 'extlang' のいずれかであるレコードに のみ現れなければならない。 o 'Scope' * Scope の field-body には、ISO 639 に従った言語コードの種類を 示す、主言語または拡張言語サブタグに関する情報が含まれる。 このフィールドで許可される値は "macrolanguage"、"collection"、 "special"、"private-use" である。このフィールドは、 'Type' の field-body が 'language' または 'extlang' の いずれかであるレコードにのみ現れる。このフィールドが 省略されている場合、その言語は個別言語である。 o 'Comments' * Comments の field-body には、レジストリを理解し、サブタグ またはタグを使用して言語タグを実装するうえで適切と 見なされる、サブタグに関する追加情報が含まれる。 この文書の将来の版では、レジストリに追加のフィールドが 追加される可能性がある。実装は、この文書で定義されていない レジストリ内のフィールドを無視すべきである。 Phillips & Davis ベスト・カレント・プラクティス [25ページ]
RFC 5646 言語タグ 2009年9月 3.1.3. Type フィールド フィールド 'Type' には、それが現れるレコードの種類を識別する 文字列が含まれる。'Type' の field-body の値は、"language" （セクション 2.2.1）、"extlang"（セクション 2.2.2）、 "script"（セクション 2.2.3）、"region"（セクション 2.2.4）、 "variant"（セクション 2.2.5）、"grandfathered" または "redundant"（セクション 2.2.8）である。 3.1.4. Subtag および Tag フィールド フィールド 'Subtag' には、レコードで定義されるサブタグが含まれる。 フィールド 'Tag' は、'Type' が 'grandfathered' または 'redundant' のいずれかであるレコードに現れ、[RFC3066] に基づいて登録された タグを含む。 'Subtag' の field-body は、セクション 2.1.1 で説明されている 大文字・小文字の慣例に従わなければならない。すべてのサブタグでは、 次の二つの例外を除き、field-body に小文字を使用する。 'Type' フィールドが 'script' であるサブタグ（言い換えれば、 ISO 15924 によって定義されたサブタグ）はタイトルケースを 使用しなければならない。 'Type' フィールドが 'region' であるサブタグ（言い換えれば、 ISO 3166-1 によって定義された非数値の地域サブタグ）は すべて大文字を使用しなければならない。 'Tag' の field-body は、セクション 2.1.1 で説明されている 規則に従って書式設定しなければならない。 3.1.5. Description フィールド フィールド 'Description' には、レコード内のタグまたはサブタグの 説明が含まれる。'Description' フィールドは一つのレコードに 複数回現れてもよい。'Description' フィールドには Unicode 文字の 全範囲を含めてもよい。少なくとも一つの 'Description' フィールドは、 ラテン文字で記述または転写しなければならない。追加の 'Description' フィールドは任意の文字体系または言語で記述してもよい。 'Description' フィールドは識別目的で使用される。 説明には、あるサブタグを混同される可能性のある他のサブタグから 区別するために必要な情報のみを、かつそのすべてを含めるべきである。 一般的な背景情報を提供したり、考えられるすべての別名または 呼称を提供したりすることを目的とするものではない。 'Description' フィールドは、必ずしもレコード内の項目の実際の 現地語名を表すものではなく、また、いずれの説明も特定の言語 （たとえば英語やフランス語）であることは保証されない。 Phillips & Davis ベスト・カレント・プラクティス [26ページ]
RFC 5646 言語タグ 2009年9月 レジストリ内の ISO 639、ISO 15924、ISO 3166-1、または UN M.49 コードに対応する説明は、その識別子がレジストリに追加された 時点、またはその後の登録によって安定性規則（セクション 3.4）の 範囲内で変更された時点において、出典規格で定義された意味を 示すことだけを目的としている。'Description' は出典規格自体の 内容を置き換えるものではない。'Description' フィールドは、 サブタグのローカライズされた英語名を提供することを目的として いない。言語タグおよびサブタグの説明のローカライズまたは翻訳は、 この文書の範囲外である。 出典規格（ISO 639 や ISO 15924 など）から取得されたサブタグでは、 レコード内の 'Description' フィールドも当初はその出典規格から 取得される。出典規格内の複数の説明は、個別の 'Description' フィールドに分割される。出典規格の説明は、挿入前または登録手続きを 通じて編集または変更してもよく、追加的または余分な説明を 省略または削除してもよい。各 'Description' フィールドは、 それが現れるレコード内で一意でなければならず、同一の説明について 書式だけが異なるものを、そのレコード内に含めるべきではない。 たとえば、ISO 639-1 コード 'fy' には、その規格内で "Western Frisian" と "Frisian, Western" の両方の説明があるが、 レジストリにはこれらの説明のうち一つだけが現れる。 ユーザーがどのサブタグを使用すべきか混乱することを防ぐため、 特定の種類（'language'、'extlang'、'script' など）のレコードに 割り当てられる 'Description' フィールドは、次の例外を除き、 そのレコード型内で一意でなければならない。特定の 'Description' フィールドが同じ種類の複数のレコードに現れる場合、 'Deprecated' フィールドを省略できるレコードは最大一つである。 'Description' を共有するすべての非推奨レコードは同じ 'Preferred-Value' を持たなければならず、すべての非非推奨レコードは その 'Preferred-Value' でなければならない。これは、同じ種類で 'Description' を共有する二つのレコードは意味的にも等価であり、 ある 'Description' に対してその意味で推奨されるレコードは 一つ以下であることを意味する。 たとえば、'language' サブタグ 'zza'（ザザ語）と 'diq' （ディムリ語）を考える。'zza' は 'diq' を包含するマクロ言語であり、 そのため ISO 639-3 では "Dimli" という説明も持っている。 衝突を防ぐため、'zza' のレジストリレコードではこの説明が "Dimli (macrolanguage)" に編集された。 一方、サブタグ 'he' と 'iw' は "Hebrew" という 'Description' 値を 共有する。これは、'iw' が非推奨で、その 'Preferred-Value' が 'he' であるため許可される。 Phillips & Davis ベスト・カレント・プラクティス [27ページ]
RFC 5646 言語タグ 2009年9月 'language' 型のフィールドでは、レジストリに最初に現れる 'Description' フィールドは、可能な場合、ISO 639-3 によって 割り当てられた Reference Name に対応する。これは ISO 639 と レジストリ間の相互参照を容易にするのに役立つ。 出典規格の一つによる変更に伴ってレコードを作成または更新する場合、 Language Subtag Reviewer は、提案レコードを ietf-languages@iana.org リストに検討のため提出する前に、 書式上の不規則性（綴り間違い、不適切なアポストロフィやその他の 句読点、過剰または不足している空白など）を修正するために 説明を編集してもよい。 3.1.6. Deprecated フィールド フィールド 'Deprecated' には、レコードが非推奨となった日付が 含まれ、セクション 3.3 で説明される保守手続き、または セクション 3.5 で説明される登録手続きを通じて、任意の レコードに追加、変更、または削除してもよい。通常、 'Deprecated' フィールドの追加は、ISO 3166 などの標準化機関が コードを撤回したことによる。'Deprecated' フィールドを持つ サブタグおよびタグは言語タグ内では有効であるが非推奨であり、 検証処理系はこれらのサブタグを生成すべきではない。 'Deprecated' フィールドを含み、対応する 'Preferred-Value' フィールドを持たないレコードには置換対応付けがないことに 注意されたい。 歴史的な一部のケースでは、元の非推奨日を再構築できなかった 可能性がある。そのような場合、レジストリには概算の日付が 記載される。一部のサブタグおよび一部の旧来または冗長なタグは、 レジストリが最初に作成される前に非推奨となっていた。 これに関する正確な規則は セクション 2 of [RFC4645] に記載されている。これらのレコードには、 対応する 'Added' フィールドよりも前の日付を持つ 'Deprecated' フィールドがあることに注意されたい。 3.1.7. Preferred-Value フィールド フィールド 'Preferred-Value' には、それが現れるレコードと、 別のタグまたはサブタグ（レコードの 'Type' に応じる）との 対応付けが含まれる。このフィールドの値は正規化に使用される （セクション 4.5 を参照）。サブタグまたはタグに 'Deprecated' フィールドもある場合、言語タグを選択するときに このレコードの値を表す最適な選択肢として 'Preferred-Value' を 使用することが推奨される。 'Preferred-Value' を含むレコードは、次の四つのグループの いずれかに分類される。 Phillips & Davis ベスト・カレント・プラクティス [28ページ]
RFC 5646 言語タグ 2009年9月 1. 後に別のコードを優先して撤回された ISO 639 言語コード。 これらの値の大半は歴史的な意味を持つだけである。 上記の 'he'/'iw' の組み合わせがその一例である。 2. 新しいコードを優先して撤回されたコードまたは値から取得された サブタグ（language または extlang 以外の型）。 特に、これは ISO 3166-1 に由来する地域サブタグに適用される。 国名または行政上の状態が、新しい地域コードを必要とするような 形で変更される場合があるためである。場合によっては、国が 以前の名称に戻り、その名称がすでに符号化されていることもある。 たとえば、サブタグ 'ZR'（ザイール）は、その国名が変更された際に サブタグ 'CD'（コンゴ民主共和国）に置き換えられた。 3. 表す値が後に符号化されたため廃止されたタグまたはサブタグ。 たとえば、多くの旧来または冗長なタグは後に ISO 639 によって 符号化され、このグループに該当する。たとえば、 "i-klingon" はサブタグ 'tlh' が追加された際に非推奨となった。 "i-klingon" のレコードは 'tlh' という 'Preferred-Value' を持つ。 4. 拡張言語サブタグは、常に同一の主言語サブタグへの対応付けを持つ。 たとえば、拡張言語サブタグ 'yue'（広東語）は、タグ "zh-yue" を 形成するために使用できる。これは主言語サブタグ 'yue' への 'Preferred-Value' 対応付けを持つ。これは、"zh-yue-Hant-HK" のようなタグを "yue-Hant-HK" に正規化できることを意味する。 'Preferred-Value' フィールドを含む 'extlang' 型以外のレコードは、 'Deprecated' フィールドも持たなければならない。このフィールドには、 推奨値を優先してタグまたはサブタグが非推奨となった日付が含まれる。 'extlang' 型のレコードでは、'Preferred-Value' フィールドは対応する 'Deprecated' フィールドなしで現れる。実装はこれらの推奨値の 対応付けを無視してもよいが、無視する場合は一貫してそうすべきである。 また、'Preferred-Value' を対応付けられた項目と等価として扱うべきである。 たとえば、タグ "zh-yue-Hant-HK" と "yue-Hant-HK" は意味的に 等価であり、同じタグであるかのように扱うのが望ましい。 場合によっては、非推奨コードが特定の文脈で推奨されることがある。 たとえば、Java プログラミング言語では "iw" と "he" の両方を 使用できるが、入力時に "he" は "iw" に変換されるため、 Java では "iw" が正規形となる。 Phillips & Davis ベスト・カレント・プラクティス [29ページ]
RFC 5646 言語タグ 2009年9月 'region' 型のレコードにおける 'Preferred-Value' の対応付けは、 元の値と完全に同じ意味を表さない場合がある。国コードが変更される 理由は多数あり、それが言語タグの形成に与える影響は対象となる 変更の性質によって異なる。たとえば、地域サブタグ 'YD' （南イエメン）は、1990 年に二国が統一された際に、 サブタグ 'YE'（イエメン）を優先して非推奨となった。 'Preferred-Value' は、セクション 3.3 の規則に従ってレコードに 追加、変更、または削除してもよい。レコード内の 'Preferred-Value' フィールドの追加、変更、または削除は、影響を受けるサブタグを 使用しているコンテンツに再度タグ付けする必要があることを意味しない。 "grandfathered" および "redundant" 型のレコードにある 'Preferred-Value' フィールドは、それぞれ、そのレコードの値の代わりに 使用することが強く推奨される「拡張言語範囲」[RFC4647] を含む。 多くの場合、これらの対応付けは [RFC4646] が採用される前の期間に タグが非推奨とされたことによって作成された。たとえば、タグ "no-nyn" は ISO 639-1 で定義された言語コード 'nn' を優先して 非推奨となった。 "extlang" 型のサブタグレコードにある 'Preferred-Value' フィールドも 「拡張言語範囲」を含む。これにより、サブタグを単一の主言語サブタグ、 または新しい language-extlang シーケンスを優先して非推奨にできる。 通常、サブタグに対する 'Preferred-Value' フィールドの追加、削除、 または変更は、出典規格の一つの変更を反映するために行われる。 たとえば、ISO 3166-1 地域コードが別のコードを優先して非推奨と された場合、それにより 'Preferred-Value' フィールドを追加すべきである。 一つのサブタグの変更は、他のサブタグにも影響を与える可能性がある。 レジストリへの変更を提案するとき、Language Subtag Reviewer は、 そのような影響についてレジストリを確認し、セクション 3.5 の 手続きを使用して必要な変更を提案しなければならない。ただし、 誰でもそのような変更を要求してもよい。たとえば: サブタグ 'XX' の 'Preferred-Value' が 'YY' であるとする。 後に 'YY' の 'Preferred-Value' が 'ZZ' に変更された場合、 'XX' の 'Preferred-Value' も 'ZZ' に変更しなければならない。 登録済みの言語サブタグ 'dialect' が、まだ ISO 639 のどの部分でも 利用できない言語を表しているとする。後に対応する言語コードが ISO 639 に追加された場合、'dialect' に 'Preferred-Value' を 追加すべきである。 Phillips & Davis ベスト・カレント・プラクティス [30ページ]
RFC 5646 言語タグ 2009年9月 3.1.8. Prefix フィールド フィールド 'Prefix' には、場合によっては他のサブタグとともに、 このレコードのサブタグに対する可能な接頭辞の一つとして推奨される 有効な言語タグが含まれる。すなわち、一つ以上の 'Prefix' を持つ 拡張言語または変種サブタグを言語タグに含める場合、生成されるタグは、 "Extended Filtering" アルゴリズム（[RFC4647] を参照）を使用して、 サブタグの 'Prefix' フィールドの少なくとも一つに一致すべきであり、 その 'Prefix' 内の各サブタグはサブタグ自体より前に現れるべきである。 'Prefix' フィールドは、'extlang' 型のレコードに正確に一回 現れなければならない。'Prefix' フィールドは、'variant' 型の レコードでは複数回現れてもよい（またはまったく現れなくてもよい）。 'variant' レコードがすでに少なくとも一つの 'Prefix' フィールドを 持っている場合、この種類の追加フィールドを登録手続きを通じて 'variant' レコードに追加してもよい。 各 'Prefix' フィールドは、このサブタグと組み合わせて意味のある タグを形成する特定のサブタグシーケンスを示す。たとえば、 拡張言語サブタグ 'cmn'（官話）は、その接頭辞 'zh'（中国語）と ともに使用する場合にのみ意味を持つ。同様に、'rozaj' （レシア語、スロベニア語の方言）はその接頭辞 'sl' （スロベニア語）とともに使用するのが適切である一方、 "is-1994" のようなタグは適切ではない（おそらく意味もない）。 'rozaj' の 'Prefix' は "sl" だが、その間に他のサブタグが 現れる場合がある。たとえば、タグ "sl-IT-rozaj" （スロベニア語、イタリア、レシア語）は 'Prefix' "sl" に一致する。 'Prefix' はまた、変種サブタグを一緒に使用することに意味がある場合 （同じ 'Prefix' を共有するものの多くは相互排他的である）と、 変種の相対的な順序がどうあるべきかも示す。たとえば、変種 '1994' （標準化されたレシア語正書法）は、レジストリ内に複数の 'Prefix' フィールド（"sl-rozaj"、"sl-rozaj-biske"、 "sl-rozaj-njiva"、"sl-rozaj-osojs"、"sl-rozaj-solba"）を持つ。 これは、'1994' がこれら五つのレシア語変種サブタグ （'rozaj'、'biske'、'njiva'、'osojs'、'solba'）のそれぞれと ともに使用するのに適しているだけでなく、タグ内ではこれらの 変種の後に現れるべきであることも示す。したがって、言語タグは "sl-1994-rozaj-biske" や "sl-rozaj-1994-biske" ではなく、 "sl-rozaj-biske-1994" の形式を取るのが望ましい。 レコードに 'Prefix' フィールドが含まれていない場合、 後からそのレコードに 'Prefix' フィールドを追加してはならない。 それ以外の場合、推奨される言語タグの範囲を厳密に広げる限り、 'Prefix' フィールド集合の変更（追加、削除、または修正）を 登録してもよい。たとえば、値 "be-Latn"（ベラルーシ語、 ラテン文字）の 'Prefix' は値 "be"（ベラルーシ語）に置き換える ことができるが、値 "ru-Latn"（ロシア語、ラテン文字）や Phillips & Davis ベスト・カレント・プラクティス [31ページ]
RFC 5646 言語タグ 2009年9月 値 "be-Latn-BY"（ベラルーシ語、ラテン文字、ベラルーシ）には 置き換えられない。これら後者は、推奨されるタグの範囲を変更または 狭めるためである。 'Prefix' フィールドの field-body は、対象レコードにすでに登録されて いるいかなる 'Prefix' とも競合してはならない。このような競合は、 接頭辞を含む有効なタグを構築できない場合、たとえば二つのサブタグが それぞれ相手方のサブタグを含む 'Prefix' を持つ場合に発生する。 たとえば、サブタグ 'avariant' が接頭辞 "es-bvariant" を持つとする。 この場合、サブタグ 'bvariant' に接頭辞 'avariant' を割り当てることは できない。そうすると、"es-avariant-bvariant-avariant" という形式の タグが必要となり、これは有効ではないからである。 3.1.9. Suppress-Script フィールド フィールド 'Suppress-Script' には文字体系サブタグ （そのレコードはレジストリに存在する）が含まれる。 フィールド 'Suppress-Script' は、'Type' の field-body が 'language' または 'extlang' のいずれかであるレコードにのみ 現れなければならない。このフィールドは一つのレコードに 複数回現れてはならない。 このフィールドは、対象言語の文書の圧倒的大多数を書くために 使用される文字体系を示す。そのため、このような文字体系の サブタグは言語タグに区別上の情報を追加せず、したがって、その言語の 大多数の文書では使用すべきではない。このフィールドで示される 文字体系サブタグを省略することで、この文書の規則に従って生成された 言語タグと、RFC 3066 に基づく言語タグおよびタグ処理系または 利用者との互換性を高めることができる。たとえば、 アイスランド語文書の事実上すべてはラテン文字で記述されるため、 タグ "is-Latn" ではサブタグ 'Latn' は冗長である。 多くの言語サブタグレコードには 'Suppress-Script' フィールドがない。 'Suppress-Script' がないことは、その言語が通常複数の文字体系で 書かれること、または通常まったく書かれないことを示す場合がある。 また、レコード作成時に十分な情報が利用できなかったため、 将来の登録候補のままであることを意味する場合もある。 3.1.10. Macrolanguage フィールド フィールド 'Macrolanguage' には主言語サブタグ （そのレコードはレジストリに存在する）が含まれる。 このフィールドは、ISO 639-3 による割り当てに従って、このサブタグの 言語を包含する言語を示す。 ISO 639-3 はレジストリ内の一部の言語を "macrolanguages" と 呼んでいる。ISO 639-3 は "macrolanguage" という用語を、 Phillips & Davis ベスト・カレント・プラクティス [32ページ]
RFC 5646 言語タグ 2009年9月 「[...] 異なる個別言語と見なすことができるが、特定の使用文脈では すべてに対して単一の言語識別が必要となる、密接に関連した 言語変種の集合」と定義する。これらは、ISO 639-2 で個別言語として 登録されたコードのうち、ISO 639-3 では複数の言語に対応することが 判明したものに対応する。 マクロ言語に含まれる言語は "encompassed language" と呼ばれる。 各包含言語のレコードには、レジストリ内に 'Macrolanguage' フィールドが含まれる。マクロ言語自体には特別な印は付けられない。 一部の包含言語は ISO 639-1 または ISO 639-2 コードを持つことに 注意されたい。 'Macrolanguage' フィールドは、'language' または 'extlang' 型の レコードにのみ現れることができる。ISO 639-3 によって割り当てられた 値だけが登録対象として検討される。ISO 639-3 が新しい値を定義したり 古い値を撤回したりした場合、通常の登録手続きを通じて 'Macrolanguage' フィールドを追加または削除してもよい。 マクロ言語は参考情報であり、ISO 639-3 が値を変更した場合には 削除または変更してもよい。このフィールドの使用、および マクロ言語と包含言語のサブタグの選択についての詳細は セクション 4.1.1 を参照されたい。 たとえば、言語サブタグ 'nb'（ノルウェー語ブークモール）と 'nn' （ノルウェー語ニーノシュク）は、それぞれ値 'no' （ノルウェー語）の 'Macrolanguage' フィールドを持つ。 詳細については セクション 4.1 を参照されたい。 3.1.11. Scope フィールド フィールド 'Scope' には、ISO 639 に由来する主言語または拡張言語 サブタグに関する分類情報が含まれる。大多数の言語の scope は 'individual' であり、これはその言語がマクロ言語、集合、特殊コード、 または私的利用ではないことを意味する。すなわち、通常「一つの言語」 と考えられるものである。'Scope' フィールドを持たない主言語または 拡張言語サブタグは、すべて個別言語である。 'Scope' 情報は、ISO 639 内でコードが割り当てられた目的または 「範囲」を示すため、言語タグを選択する際に役立つことがある。 利用可能な値は次のとおりである。 o 'macrolanguage' - ISO 639-3 で定義されるマクロ言語を示す （セクション 3.1.10 を参照）。マクロ言語とは、場合によって 単一の言語と見なされる、密接に関連した言語の集合である。 o 'collection' - 通常、何らかの歴史的、地理的、または言語学的な 関連によって結び付けられた言語の集合を表すサブタグを示す。 マクロ言語とは異なり、 Phillips & Davis ベスト・カレント・プラクティス [33ページ]
RFC 5646 言語タグ 2009年9月 collection には緩やかにしか関連していない言語を含めることができ、 collection と、それに属する言語とを相互交換可能に使用することは できない。 o 'special' - 特殊な言語コードを示す。これらは、具体的な言語に 特に関連付けられていない言語的属性を識別するために使用される サブタグである。これには、言語が未確定である場合や、 非言語コンテンツの場合のコードが含まれる。 o 'private-use' - 基礎となる規格で私的利用のために予約された コードを示す。この scope を持つサブタグは、ISO 639 または 登録済みの割り当てが存在しない主言語を示すために使用できる。 'Scope' フィールドは、'language' または 'extlang' 型のレコードに 現れてもよい。拡張言語サブタグの接頭辞の多くは 'macrolanguage' という 'Scope' を持つ（ただし一部は持たない）こと、および 'macrolanguage' という 'Scope' を持つ多くの言語には、 それらに関連付けられた拡張言語サブタグがあることに注意されたい。 'Scope' フィールドは、その変更が ISO 639 による割り当て分類の 変更を反映することを条件に、登録手続きを通じて追加、変更、 または削除してもよい。このような変更はまれであると予想される。 たとえば、主言語サブタグ 'zh'（中国語）の 'Scope' は 'macrolanguage' であり、それに包含される言語 'nan'（閩南語）の 'Scope' は 'individual' である。特殊値 'und'（未確定）の 'Scope' は 'special' である。ISO 639-5 の集合 'gem' （ゲルマン諸語）の 'Scope' は 'collection' である。 3.1.12. Comments フィールド フィールド 'Comments' にはレコードに関する追加情報が含まれ、 一つのレコードに複数回現れてもよい。field-body には Unicode 文字の全範囲を含めてもよく、特定の文字体系には制限されない。 このフィールドは登録手続きを通じて挿入または変更してもよく、 安定性についての保証は提供されない。 このフィールドの内容は、情報を登録する必要性、要求の適切性、 および合理的で実務的なサイズ制限を除き、制限されない。 'Comments' フィールドの主な目的はサブタグの識別、すなわち 使用の助けとして、混同される可能性のある他のサブタグから そのサブタグを区別することである。サブタグの使用、歴史、 または一般的な背景について大量の情報を含めることは好ましくない。 そのような情報は通常、レジストリではなく登録要求に含めるべきだからである。 Phillips & Davis ベスト・カレント・プラクティス [34ページ]
RFC 5646 言語タグ 2009年9月 3.2. Language Subtag Reviewer Language Subtag Reviewer は ietf-languages@iana.org メーリングリストを モデレートし、登録要求に応答し、セクション 3.3 で説明されるその他の レジストリ保守業務を行う。IANA に対して Language Subtag Registry の レコードの変更、更新、または追加を要求することが許可されるのは Language Subtag Reviewer だけである。Language Subtag Reviewer は、 必要に応じてリストのモデレーションやその他の事務的業務を 委任してもよい。 Language Subtag Reviewer は IESG によって任期を定めずに任命され、 IESG の裁量により解任または交代させることができる。IESG は （この文書の採用時または欠員発生時に）この役職の候補者を募集し、 その後、候補者の資格について意見を募集する。適格な候補者は BCP 47 とその要件に精通し、登録手続きを公平、迅速かつ慎重に 運営する意思があり、レビュアーが主張を評価し、言語専門家および サブタグ要求者の貢献を活用できるよう、言語識別の問題について 十分な知識を持つべきである。 Language Subtag Reviewer のその後の業務または決定は、他の IETF の決定と同じ規則に基づいて IESG に異議申し立てしてもよい （[RFC2026] を参照）。IESG は Language Subtag Reviewer の決定を 取り消しまたは覆し、指針を提供し、その他の適切な措置を 講じることができる。 3.3. レジストリの保守 レジストリの保守では、ISO 639、ISO 15924、ISO 3166、および UN M.49 によってコードが割り当てまたは撤回されるたびに、 Language Subtag Reviewer が各変更を評価し、この文書の規則に 従って適切な対応方針を決定しなければならない。このような更新は セクション 3.5 で説明される登録手続きに従う。通常、 Language Subtag Reviewer は登録フォームに記入して提出することで、 新しいレコードまたは更新されたレコードの手続きを開始する。 これらの規格のいずれかに変更があり、Language Subtag Reviewer が 適時にこれを行わない場合、任意の利害関係者がフォームを 提出してもよい。その後、登録手続きは通常どおり続行される。 一部の登録は、地域サブタグが新しい値を優先して非推奨となる場合の ように、他のサブタグ（場合によっては複数）にも影響を与えることに 注意されたい。Language Subtag Reviewer は、そのような変更が 適切に登録されることを保証する責任を負い、各変更にはそれぞれ 独自の登録フォームが必要となる。 Phillips & Davis ベスト・カレント・プラクティス [35ページ]
RFC 5646 言語タグ 2009年9月 Language Subtag Reviewer は、新しいサブタグがこの文書の他の箇所 （特に セクション 3.4）の要件を満たすことを保証するか、 または同セクションで説明されている代替サブタグについて適切な 登録フォームを提出しなければならない。変更の影響を受ける 各サブタグは、それぞれ独自の登録フォームを添え、別個のメッセージで ietf-languages@iana.org リストに送信しなければならない。 3.4. IANA レジストリエントリの安定性 レジストリ内のエントリとその意味の安定性は、言語タグの長期的な 安定性にとって極めて重要である。このセクションの規則は、 特定の言語タグの意味が長期にわたって安定し、変更されないことを 保証する。 これらの規則は特に、ISO 639、ISO 15924、ISO 3166、および UN M.49 によって保守されるコードの変更（コードの撤回および 非推奨化を含む）が IANA 言語サブタグレジストリにどのように 反映されるかを扱う。IANA 言語サブタグレジストリへの割り当ては、 次の安定性規則に従わなければならない。 1. フィールド 'Type'、'Subtag'、'Tag'、および 'Added' の値は 変更してはならず、長期にわたって安定することが保証される。 2. フィールド 'Preferred-Value' および 'Deprecated' の値は、 登録手続きを通じて追加、変更、または削除してもよい。 これらの変更は、基礎となる規格（ISO 639、ISO 15924、 ISO 3166-1、または UN M.49）の一つにおける変更を反映するために 必要な変更に限定すべきであり、通常、'Preferred-Value' の 変更または削除は特に地域コードに限定される。 3. 'Description' フィールドの値は、既存のタグを無効にするような 方法で変更してはならない。説明は、範囲をある程度広げたり、 情報を追加するように変更したり、最も一般的な現代の用法に 合わせたりしてもよい。たとえば、国は時折名称を変更する。 歴史的な例として "Upper Volta" から "Burkina Faso" への 変更がある。 4. 'Prefix' フィールドの値は、'variant' がすでに少なくとも一つの 'Prefix' を持っている場合に限り、登録手続きを通じて既存の 'variant' 型レコードに追加してもよい。既存の 'Prefix' フィールドを持たない 'variant' に 'Prefix' フィールドを 登録してはならない。variant レコードに prefix が追加された場合、 各種 prefix での異なる使用法を説明するために 'Comment' フィールドを使用してもよい。 Phillips & Davis ベスト・カレント・プラクティス [36ページ]
RFC 5646 言語タグ 2009年9月 5. 'variant' 型のレコードにある 'Prefix' フィールドの値も、 変更によって prefix の集合が広がる限り変更してもよい。 すなわち、ある prefix は、その prefix 自身の prefix の一つに 置き換えてもよい。たとえば、prefix "en-US" は "en" に 置き換えることができるが、prefix "en-Latn"、"fr"、 または "en-US-boont" には置き換えられない。これらの prefix 値の 一つが必要な場合は、別途登録しなければならない。 6. 'extlang' 型のレコードにある 'Prefix' フィールドの値は、 追加、変更、または削除してはならない。 7. 'Prefix' フィールドは、それが現れるいかなるレコードからも 削除してはならない。このフィールドは、'variant' 型の レコードの初期登録時に含めるべきであり、'extlang' 型の レコードには含めなければならない。 8. 'Comments' フィールドは、登録手続き、またはこのセクションで 説明されているいずれかの手続きもしくは考慮事項を通じて、 追加、変更、修正、または削除してもよい。 9. 'Suppress-Script' フィールドは、登録手続きを通じて 追加または削除してもよい。 10. 'Macrolanguage' フィールドは、登録手続きを通じて追加または 削除してもよいが、ISO 639 によって行われた変更に応じる場合に 限られる。'Macrolanguage' フィールドは、ある言語が ISO 639 で 対応するマクロ言語を持つ場合は常に現れる。すなわち、 レジストリ内の 'Macrolanguage' フィールドは ISO 639 のものと 正確に一致する。その他のマクロ言語対応付けは登録対象として 検討されない。 11. 'Scope' フィールドは、初期登録後に主言語または拡張言語サブタグ から追加または削除してもよく、ISO 639 によって行われた変更に 一致させるために変更してもよい。'Scope' フィールドへの変更は ISO 639 によって行われた変更を反映しなければならない。 レコードに 'Scope' フィールドを含まない主言語または 拡張言語サブタグ（すなわち、その大半）は、 セクション 3.1.11 で説明されている個別言語であることに注意されたい。 12. 主言語および拡張言語サブタグ（登録手続きを使用して独立して 登録された値を除く）は、ISO 639 の各部の割り当てに従って、 次のように作成される。 A. 既存の 2 文字の主言語サブタグと競合せず、レジストリ内に 対応する 3 文字の主言語が定義されていない ISO 639-1 によって割り当てられたコードは、新しいレコードとして IANA レジストリに登録される Phillips & Davis ベスト・カレント・プラクティス [37ページ]
RFC 5646 言語タグ 2009年9月 'language' 型のレコードとして登録される。ISO 639-1 コードが付与された言語には、たとえマクロ言語に 包含されていても、拡張言語サブタグを付与できないことに注意されたい。 B. 既存の 3 文字の主言語サブタグと競合せず、 ISO 639-1 コードが割り当てられていない（または 割り当てられる予定がない）ISO 639-3 または ISO 639-5 によって 割り当てられたコードは、新しい 'language' 型レコードとして IANA レジストリに登録される。これら二つの規格は現在、 ISO 639-2 コードのスーパーセットを構成していることに注意されたい。 登録時に定義済みの 'macrolanguage' 対応付けを持つコードは、 'Macrolanguage' フィールドを含まなければならない。 C. ISO 639-3 によって割り当てられたコードは、拡張言語 サブタグ登録の対象として検討してもよい。'extlang' レコードが提案される場合でも、'language' 型の主言語 サブタグレコードを割り当てなければならないことに注意されたい。 拡張言語サブタグの割り当てを検討する場合、次の基準を適用する。 1. ある言語にマクロ言語の対応付けがあり、その マクロ言語に、拡張言語サブタグが割り当てられた 他の包含言語がある場合、新しい言語にも 'extlang' レコードを割り当てるべきである。 たとえば、マクロ言語が 'zh' または 'ar' である言語には、 'extlang' レコードが割り当てられる。 2. マクロ言語に包含される他の言語にも 'extlang' レコードが含まれていない場合、その言語について 'extlang' レコードを作成すべきではない。たとえば、 新しいセルビア・クロアチア語 ('sh') が登録された場合、 セルビア語 ('sr') など他の包含言語がレジストリ内に extlang レコードを含まないため、extlang レコードは 付与されない。 3. 手話には、'sgn' の 'Prefix' を持つ 'extlang' レコードを設けるべきである。 4. レジストリにすでに存在する項目について 'Extlang' レコードを作成してはならない。拡張言語サブタグは、 初回登録時にのみ検討される。 5. 拡張言語サブタグレコードには、 セクション 2.2.2 に記載されているとおりに値が割り当てられた 'Prefix' および 'Preferred-Value' フィールドを 含めなければならない。 D. 既存の 3 文字の主言語または拡張言語 Phillips & Davis ベスト・カレント・プラクティス [38ページ]
RFC 5646 言語タグ 2009年9月 サブタグと競合せず、ISO 639-1 の 2 文字コードも 割り当てられていない、ISO 639-2 によって割り当てられた その他のコードは、新しい 'language' 型レコードとして IANA レジストリに登録される。この種類の登録は、 将来発生しないものと想定されている。 13. 関連する種類の既存サブタグと競合せず、同じ種類の既存サブタグと 意味が同一でない ISO 15924 および ISO 3166-1 によって 割り当てられたコードは、新しいレコードとして IANA レジストリに 登録される。 14. ISO 639、ISO 15924、または ISO 3166-1 によって割り当てられ、 それぞれの保守機関または登録機関によって撤回されたコードは、 言語タグ内では引き続き有効である。撤回日を含む 'Deprecated' フィールドをレコードに追加しなければならない。 置換値を表す同じ種類の新しいレコードが追加された場合、 'Preferred-Value' フィールドも追加してもよい。各規格による コードの撤回についてコメントを追加するために、 登録手続きを使用してもよい。 例: 地域コード 'TL' は国 'Timor-Leste' に割り当てられ、 コード 'TP'（ポルトガルの統治下にあった時期の 'East Timor' に割り当てられていた）を置き換えた。 サブタグ 'TP' は言語タグ内では引き続き有効だが、その レコードには 'Preferred-Value' として 'TL' が含まれ、 'Deprecated' フィールドには新しいコードが割り当てられた 日付 ('2004-07-06') が含まれる。 15. ISO 639、ISO 15924、または ISO 3166-1 によって割り当てられ、 非推奨のサブタグを含む、関連する種類の既存サブタグと 競合するコードは、レジストリに登録してはならない。 再割り当てされたサブタグ値には、さらに次の考慮事項が適用される。 A. ISO 639 コードについて、新たに割り当てられたコードの意味が IANA レジストリ内のサブタグによって表されていない場合、 Language Subtag Reviewer は、セクション 3.5 に記載されているとおり、 実務上可能な限り速やかに、新しいコードの代替値として 登録済み言語サブタグを IANA レジストリに登録するための 提案を作成しなければならない。登録済み言語サブタグの 形式は Language Subtag Reviewer の裁量によるものとし、 この文書における言語サブタグに対するその他の制約に 適合しなければならない。 B. 外部規格（すなわち ISO 639、ISO 15924、ISO 3166-1、 または UN M.49）から意味が派生するすべてのサブタグについて、 既存コードに新しい意味が割り当てられ、その新しい意味が そのコードの意味を広げる場合、関連付けられたサブタグの 意味をそれに合わせて変更してもよい。 Phillips & Davis ベスト・カレント・プラクティス [39ページ]
RFC 5646 言語タグ 2009年9月 ただし、サブタグの意味を狭めてはならない。そうすると、 サブタグの既存の使用のうち割合不明のものが無効になる 可能性があるためである。注: ISO 639 登録機関 (RA) も 同様の安定性方針を採用している。 C. ISO 15924 コードについて、新たに割り当てられたコードの 意味が IANA レジストリ内のサブタグによって表されていない 場合、Language Subtag Reviewer は、セクション 3.5 に 記載されているとおり、実務上可能な限り速やかに、 新しいコードの代替値として登録済み変種サブタグを IANA レジストリに登録するための提案を作成しなければならない。 登録済み変種サブタグの形式は Language Subtag Reviewer の 裁量によるものとし、この文書における変種サブタグに対する その他の制約に適合しなければならない。 D. ISO 3166-1 コードについて、新たに割り当てられたコードの 意味が別の 'region' サブタグと同じ UN M.49 コードに 関連付けられている場合、既存の地域サブタグがその地域の 推奨値のままとなり、新しいエントリは作成されない。 新しい ISO 3166-1 コードとの関係を示すコメントを、 既存の地域サブタグに追加してもよい。 E. ISO 3166-1 コードについて、新たに割り当てられたコードの 意味が、既存の地域サブタグによって表されていない UN M.49 コードに関連付けられている場合、Language Subtag Reviewer は、セクション 3.5 に記載されているとおり、 適切な UN M.49 国コードを IANA レジストリのエントリとして 登録する提案を作成しなければならない。 F. ISO 3166-1 コードについて、関連付けられた UN 数値コードが 存在しない場合、Language Subtag Reviewer は UN に対して その作成を請願しなければならない。要求の送信から 90 日以内に UN から応答がない場合、Language Subtag Reviewer は、 実務上可能な限り速やかに、新しいコードの代替値として 登録済み変種サブタグを IANA レジストリに登録するための 提案を作成しなければならない。登録済み変種サブタグの 形式は Language Subtag Reviewer の裁量によるものとし、 この文書における変種サブタグに対するその他の制約に 適合しなければならない。この状況が実際に発生する可能性は 極めて低い。 16. UN M.49 には、「国および地域」のコード（ドイツを表す '276' など）と「地理的地域および下位地域」のコード（ヨーロッパを 表す '150' など）の両方がある。対応する ISO 3166-1 コードが 存在しない UN M.49 の国または地域コードは、既存のサブタグに よって登録が妨げられている ISO 3166-1 コードの代替として 使用する場合を除き、登録してはならない。 Phillips & Davis ベスト・カレント・プラクティス [40ページ]
RFC 5646 言語タグ 2009年9月 そのようなコードが必要になった場合、まず ISO 3166-1 の 保守機関に、その地域へのコード割り当てを請願しなければならない。 ISO 3166-1 によるコード割り当ての請願が拒否されるか、 適時に処理されない場合、その後 セクション 3.5 に記載された 登録手続きを使用して、対応する UN M.49 コードを登録できる。 このようにして、UN M.49 コードは、ISO 3166-1 がレジストリ内の 非推奨値を再割り当てした場合の最後の手段として利用可能なままとなる。 17. 冗長および旧来のエントリを合わせると、[RFC3066] に基づいて 登録されたタグの完全な一覧となる。冗長タグとは、以前に 登録されたタグのうち、現在ではレジストリで定義された サブタグを使用して形成できるものである。旧来のエントリには、 'irregular' であるため決して合法にならないもの （すなわち、図 1 の 'langtag' 生成規則に一致しないもの）、 規則によって制限されているもの（'nyn' や 'min' などの サブタグは extlang 生成規則に一致するように見えるが、 拡張言語サブタグとして登録できない）、またはサブタグが 登録に適さないものが含まれる。すべての旧来のタグは、 ABNF の 'regular' または 'irregular' のいずれかの 生成規則に列挙されている。[RFC4646] の下では、 旧来のタグが冗長になることが可能であった。しかし、 それが可能であったすべてのタグは、この文書が作成される前に 冗長となった。したがって、冗長および旧来のタグの集合は現在、 永続的かつ不変である。どちらの種類についても新しいエントリを 追加してはならず、既存のエントリを削除してはならない。 どのタグが当初旧来とされ、どのタグが冗長とされたかに関する 意思決定手続きは [RFC4645] に記載されている。 旧来のタグの多くは非推奨であり、実際、それらは [RFC4646] より前から非推奨であった。たとえば、タグ "art-lojban" は主言語サブタグ 'jbo' を優先して非推奨とされた。 これらのタグは、そのサブタグの一部を 'variants' として 登録することで 'redundant' にすることもできた。 旧来の登録内にある 'variant-like' サブタグは、同様または 同一の意味を持つ場合であっても、将来登録してはならない。 3.5. サブタグの登録手続き 現在 IANA 言語サブタグレジストリに存在しないサブタグを 使用したい者、またはこの文書で許可されている範囲で既存レコードの 情報を追加、変更、更新、または削除したい者は、ここに示す 手続きを使用しなければならない。 新しいサブタグの独立した登録について検討されるのは、 'language' および 'variant' 型のサブタグだけである。安定性のために必要な Phillips & Davis ベスト・カレント・プラクティス [41ページ]
RFC 5646 言語タグ 2009年9月 サブタグ、およびこの文書で定義された範囲内でレジストリを ISO 639、ISO 15924、ISO 3166、および UN M.49 と同期させるために 必要なサブタグも、セクション 3.3 に記載され、 セクション 3.4 に記載された安定性規定に従って、この手続きを使用する。 サブタグのレコード内の 'Comments'、'Deprecated'、'Description'、 'Prefix'、'Preferred-Value'、'Macrolanguage'、または 'Suppress-Script' フィールドに関する情報については、 セクション 3.4 に記載されているとおり登録要求を受け付ける。 IANA レジストリ内のその他すべてのフィールドへの変更は 許可されない。 新しいサブタグの登録、または既存のタグもしくはサブタグの 変更要求は、要求者が以下に再掲する登録フォームに記入することから 始まる。登録について十分に説明できるよう、各回答のサイズに 制限はないことに注意されたい。"Record Requested" セクション内の フィールドは、レコードが承認される前に セクション 3.1 の 要件に従う必要がある。 言語サブタグ登録フォーム 1. 要求者の氏名: 2. 要求者の電子メールアドレス: 3. 要求するレコード: Type: Subtag: Description: Prefix: Preferred-Value: Deprecated: Suppress-Script: Macrolanguage: Comments: 4. サブタグの意図する意味: 5. 言語について公開された説明 （書籍または論文）への参照: 6. その他の関連情報: 図 5: 言語サブタグ登録フォーム 記入済み登録フォームの例は 付録 B にある。 承認済み登録フォームの完全な一覧は http://www.iana.org からオンラインで入手できる。Language Tag Registry は現在廃止されており、代わりに Language Subtag Registry を参照すべきであることに注意されたい。 Phillips & Davis ベスト・カレント・プラクティス [42ページ]
RFC 5646 言語タグ 2009年9月 サブタグ登録フォームは <ietf-languages@iana.org> に送信しなければならない。登録要求には、 承認され IANA に提出されてレジストリに収録される前に、2 週間の レビュー期間が設けられる。登録手続きの過程で要求に変更が加えられた 場合（セクション 3.1 の要件を満たすための修正や、対象レコード型について 'Description' フィールドを一意にするための修正など）、変更後の フォームも、IANA に提出する少なくとも 1 週間前までに <ietf-languages@iana.org> に送信しなければならない。 ietf-languages リストは公開リストであり、 <ietf-languages-request@iana.org> に要求を送信することで 参加できる。このリストは IESG の要求により、IANA または 任意の第三者がホストできる。 登録を IANA に転送する前に、Language Subtag Reviewer は、 この文書のすべての要件が満たされていることを保証しなければならない。 これには、'Subtag' フィールド内の値が セクション 3.1.4 の 説明に従った大文字・小文字になっていること、および セクション 3.1.5 に記載されているように 'Description' フィールドが対象レコード型について一意であることの保証が含まれる。 Reviewer はさらに、IANA がレジストリを更新する際の助けとなるよう、 適切な File-Date レコードが要求に含まれていることを 保証しなければならない（セクション 5.1 を参照）。 登録フォームおよびレジストリレコード自体の一部のフィールドでは、 非 ASCII 文字の使用が許可されている。一貫性と明確性のため、 登録要求は UTF-8 エンコーディングを使用すべきである。 ただし、一部のメールクライアントはこのエンコーディングを サポートしないため、登録要求には他のエンコーディングを 使用してもよい。Language Subtag Reviewer は、保存される 要求フォームとレジストリレコードの両方に適切な Unicode 文字が 現れることを保証する責任を負う。IANA による転写または エンコーディングの誤りがあった場合、Language Subtag Reviewer は、 IANA を支援するために必要な情報を提供して、レジストリの修正を要求する。 拡張言語サブタグ（'extlang' 型）は、定義上、常に別の言語に 包含される。したがって、すべての 'extlang' 型レコードは 登録時に 'Prefix' フィールドを含まなければならない。 この 'Prefix' フィールドは決して変更または削除できず、 そのような要求は拒否しなければならない。 変種サブタグは通常、特定範囲の言語タグとともに使用するために 登録され、適用される言語の用語に基づく変種サブタグが推奨される。 たとえば、サブタグ 'rozaj'（レシア語）は、レシア語が スロベニア語の方言であるため、主言語サブタグ "sl" （スロベニア語）で始まる言語タグとともに使用することを 意図している。したがって、サブタグ 'rozaj' は "sl-Latn-rozaj" や "sl-IT-rozaj" などのタグに適している。 この情報はレジストリの 'Prefix' フィールドに保存される。変種 Phillips & Davis ベスト・カレント・プラクティス [43ページ]
RFC 5646 言語タグ 2009年9月 の登録要求には、登録フォーム内に少なくとも一つの 'Prefix' フィールドを含めるべきである。 既存のサブタグ値を使用して同じ種類の追加レコードを割り当てる要求は、 拒否しなければならない。たとえば、変種サブタグ 'rozaj' は すでにレジストリに存在するため、サブタグ 'rozaj' を持つ 2 番目の 'variant' 型レコードの追加は禁止される。 登録済みの特定の変種サブタグに対する 'Prefix' フィールドは、 使用方法の指針として IANA レジストリ内に存在する。 追加の登録フォームを提出することで、追加の 'Prefix' フィールドを 加えてもよい。そのフォームでは、"Any other relevant information:" フィールドに、prefix の追加であることを明記しなければならない。 異なる意味を示唆する 'Prefix' フィールドを変種サブタグに追加する 要求は拒否すべきである。たとえば、タグ "de-1994" が何らかの ドイツ語方言または正書法形式を表すようにするため、 サブタグ '1994' に prefix "de" を追加する要求は拒否される。 '1994' サブタグは特定のスロベニア語正書法を表しており、 追加登録によってサブタグに割り当てられた意味が変更または 曖昧になるためである。代わりに別のサブタグを提案すべきである。 現在 'Prefix' フィールドを持たない変種サブタグに 'Prefix' を 追加する要求は拒否しなければならない。prefix のない変種は、 多数またはすべての言語で利用できる可能性があるため、 prefix なしで登録される。一つ以上の 'Prefix' フィールドを 追加すると、サブタグの範囲が大幅に狭まるため、変種の使用に 有害となる可能性がある（これは、通常 'Prefix' の追加によって 行われるサブタグ範囲の拡大とは異なり、安定性規則 （セクション 3.4）では許可されない）。このような "no-prefix" 変種の例は、国際音声記号を表すサブタグ 'fonipa' であり、多くの言語の転写に使用できる体系である。 要求で提供される 'Description' フィールドには、ラテン文字で 記述または転写された説明を少なくとも一つ含めなければならない。 要求には、任意の文字体系または言語による追加の 'Description' フィールドを含めてもよい。'Description' フィールドは識別目的で 使用され、必ずしも言語または変種の実際の現地語名を表すものではない。 また、特定の言語である必要もないが、レコード内の項目を識別するのに 適切かつ十分なものであるべきである。Language Subtag Reviewer は、 一意性を保証し、同じ種類の他のレコード内の 'Description' フィールドとの衝突を防ぐため、提案された 'Description' フィールドを確認して編集する。独立した登録要求でこれが発生した場合、 Language Subtag Reviewer は、そのレコードを <ietf-languages@iana.org> に再提出し、 Phillips & Davis ベスト・カレント・プラクティス [44ページ]
RFC 5646 言語タグ 2009年9月 要求の唯一の目的が重複する 'Description' フィールドを導入する ことであり、その場合には要求を拒否しなければならない場合を除き、 セクション 3.5 に記載されるように、議論による要求の変更として扱わなければならない。 'Description' フィールドの安定性は保証されない。意図の訂正または 明確化は、考えられる変更の例である。レジストリ内のエントリの 翻訳または転写（定義上、新しい情報を何も提供しない）を提供しようと する試みは、承認される可能性が低い。 2 週間のレビュー期間が終了した後、Language Subtag Reviewer は 速やかに次のいずれかの措置を取らなければならない。 o 要求を明示的に受理し、セクション 3.3 に記載された手続きに従って、 挿入または変更されるレコードを含むフォームを <iana@iana.org> に転送する。 o リスト上で重大な異議が提起されたこと、またはこの文書の 制約に関する問題（明示的に引用しなければならない）があるため、 要求を明示的に拒否する。 o さらなる議論を可能にするため、追加の 2 週間単位を付与して レビュー期間を延長する。各 2 週間単位の終了後、 Language Subtag Reviewer は、登録が受理、拒否、または延長されたかを リスト上で示さなければならない。 Language Subtag Reviewer 自身も、希望する場合にはリスト上で 異議を提起してもよいことに注意されたい。重要なのは、 異議を公開で表明しなければならないことである。 レビュー期間中の議論またはこの文書の要件によって、 要求を変更する必要が生じることがある。申請者、Language Subtag Reviewer、またはその他の者は、記入済み登録フォームの変更版を 提出してもよく、申請者の明示的な承認があれば、元の要求の代わりに それが検討される。このような変更によって 2 週間の議論期間が 再開始されることはない。ただし、IANA に提出される最終レコードを 含む申請は、Language Subtag Reviewer がレコードを IANA に 転送する少なくとも 1 週間前までにリストに掲載されなければならない。 申請者は、拒否された申請を、より適切または追加の情報を用いて 変更し、再提出してもよい。その場合、新たな 2 週間のコメント期間が 開始される。 セクション 3.3 または セクション 3.4 の規定によって開始された登録は、最終的には レジストリに掲載されなければならないため、全面的に拒否しては ならず、可能な限り迅速に完了すべきである。レビュー手続きにより、 リストの参加者はフォーム内の具体的な情報およびそこに含まれる レコードについてコメントでき、 Phillips & Davis ベスト・カレント・プラクティス [45ページ]
RFC 5646 言語タグ 2009年9月 その結果、それが正確かつ一貫していることの確保に役立つ。 Language Subtag Reviewer はフォームの特定の版を拒否してもよいが、 フォームがレビュアーの承認に値する形式となり、リストのおおよその 合意を得るまで、上記のとおりレビュー期間を延長しながら、 適切な代替案を提案しなければならない。 Language Subtag Reviewer による決定は、他の IETF の決定 [RFC2026] と同じ規則に基づいて IESG [RFC2028] に 異議申し立てしてもよい。これには、レビュー期間を延長する決定や、 明確かつ適時に決定を発表しなかったことも含まれる。 承認されたレコードは Language Subtag Registry に掲載される。 承認された登録フォームは http://www.iana.org からオンラインで入手できる。 既存レコードの更新または変更は、新規登録と同じ手続きに従う。 Language Subtag Reviewer は、2 週間のレビュー期間後、 登録を更新することについて合意があるかどうかを判断する。 通常、元の登録者による異議は、そのような合意形成において より大きな重みを持つ。 登録は永続的かつ安定している。一度登録されると、サブタグは レジストリから削除されず、特定の言語または変種を指定する 有効な方法として維持される。 注: 登録フォーム内の "Reference to published description" セクションの目的は、ある言語が登録済みかどうか、または特定の サブタグがどの言語または言語変種を指すかを検証する助けとなる ことである。大多数の場合、その言語について権威ある文法書または 辞書を参照することが有用である。そのような著作が存在しない場合、 その言語を説明する、またはその言語で書かれた他の著名な著作が 適切である場合もある。Language Subtag Reviewer は、何が 「十分に適切な」参考資料であるかを判断する。この要件は、 話者人口の規模や標準化された正書法の欠如を理由に、 特定の言語または方言を排除することを意図していない。 少数言語も、それ自体の価値に基づいて同等に検討される。 3.6. 登録の可能性 サブタグまたはサブタグに関する情報を登録できる可能性には、 次のものが含まれる。 o ISO 639 に掲載されておらず、掲載済みまたは登録済みのいかなる 言語の変種でもない言語の主言語サブタグは登録してもよい。 この文書が作成された時点では、この形式のサブタグの例は 存在しなかった。言語サブタグの登録を試みる前に、 その言語を登録する試みを Phillips & Davis ベスト・カレント・プラクティス [46ページ]
RFC 5646 言語タグ 2009年9月 ISO 639 に対して行わなければならない。ISO 639-1、ISO 639-2、 または ISO 639-3 に存在するコードによって定義される言語、 ISO 639 登録機関で検討中の言語、またはそれらの機関に対して 登録を試みたことが一度もない言語について、サブタグを 登録してはならない。ISO 639 が以前に言語の登録を拒否している 場合、それが IANA レジストリで主言語サブタグとして登録される ためには、必要性を示す追加の非常に説得力のある証拠が 必要であると考えるのが妥当である（この種類のサブタグが 登録される可能性は極めて低い）。 o 言語内の方言その他の区分または変異、その正書法、文字体系、 地域的もしくは歴史的用法、翻字その他の変換、または区別される 変異は、変種サブタグとして登録してもよい。その一例が 'rozaj' サブタグ（スロベニア語のレシア方言）である。 o セクション 3.1 に記載されているように、タグまたはサブタグレコード内の フィールド（一般に参考情報としての性質を持つ）を追加または 保守することが許可される。このような変更には セクション 3.4 の安定性規定が適用される。これには、 廃止または撤回されたコードに対する 'Description'、 'Comments'、'Deprecated'、'Preferred-Value' フィールド、 主言語サブタグへの 'Suppress-Script' または 'Macrolanguage' フィールドの追加、および変種サブタグへの適切な 'Prefix' フィールドの追加など、この文書で許可されるその他の変更が含まれる。 o セクション 3.4 に記載されているように、ISO 639、ISO 15924、 ISO 3166-1、および UN M.49 による割り当てを反映するために 必要なレコードの追加および関連するフィールド値の変更が許可される。 旧来のタグの全部または一部を冗長にすることになるが、その意味が 旧来のタグの意味と競合または変更する登録提案サブタグは 拒否しなければならない。 この文書は、どのサブタグまたはサブタグへの変更が適切か （または適切でないか）の判断を、セクション 3.5 に記載された 登録手続きに委ねる。 注: 4 文字の主言語サブタグは、将来 ISO 639 規格群に alpha4 コードが追加される可能性に備えて予約されている。 ISO 639 は、ISO 639 の言語一覧への追加および変更のための 登録機関を定義している。この機関は次のとおりである。 Phillips & Davis ベスト・カレント・プラクティス [47ページ]
RFC 5646 言語タグ 2009年9月 International Information Centre for Terminology (Infoterm) Aichholzgasse 6/12, AT-1120 Wien, Austria 電話: +43 1 26 75 35 Ext. 312 ファックス: +43 1 216 32 72 ISO 639-2 は、ISO 639-2 の言語一覧への追加および変更のための 登録機関を定義している。この機関は次のとおりである。 Library of Congress Network Development and MARC Standards Office Washington, DC 20540, USA 電話: +1 202 707 6237 ファックス: +1 202 707 0115 URL: http://www.loc.gov/standards/iso639-2 ISO 639-3 は、ISO 639-3 の言語一覧への追加および変更のための 登録機関を定義している。この機関は次のとおりである。 SIL International ISO 639-3 Registrar 7500 W. Camp Wisdom Rd. Dallas, TX 75236, USA 電話: +1 972 708 7400, ext. 2293 ファックス: +1 972 708 7546 電子メール: iso639-3@sil.org URL: http://www.sil.org/iso639-3 ISO 639-5 は、ISO 639-5 の言語一覧への追加および変更のための 登録機関を定義している。この機関は ISO 639-2 と同じであり、 次のとおりである。 Library of Congress Network Development and MARC Standards Office Washington, DC 20540, USA 電話: +1 202 707 6237 ファックス: +1 202 707 0115 URL: http://www.loc.gov/standards/iso639-5 ISO 3166-1（国コード）の保守機関は次のとおりである。 ISO 3166 Maintenance Agency c/o International Organization for Standardization Case postale 56 CH-1211 Geneva 20, Switzerland 電話: +41 22 749 72 33 ファックス: +41 22 749 73 49 URL: http://www.iso.org/iso/en/prods-services/iso3166ma/index.html Phillips & Davis ベスト・カレント・プラクティス [48ページ]
RFC 5646 言語タグ 2009年9月 ISO 15924（文字体系コード）の登録機関は次のとおりである。 Unicode Consortium Box 391476 Mountain View, CA 94039-1476, USA URL: http://www.unicode.org/iso15924 国際連合事務局統計部は、統計用途の標準国・地域コードを 保守しており、連絡先は次のとおりである。 Statistical Services Branch Statistics Division United Nations, Room DC2-1620 New York, NY 10017, USA ファックス: +1-212-963-0623 電子メール: statistics@un.org URL: http://unstats.un.org/unsd/methods/m49/m49alpha.htm 3.7. 拡張および拡張レジストリ 拡張サブタグとは、'x' 以外の 1 文字のサブタグ ("singletons") によって導入されるものである。これらは、 言語要素を含み、言語タグを理解するアプリケーションと互換性のある 識別子を生成するために予約されている。 拡張の構造と形式はこの文書によって定義されており、将来 singleton を 使用して作成される可能性のあるアプリケーションと前方互換性を持つ 実装を作成できるようにしている。さらに、singleton を保守する 機構を定義することで、将来の改訂または更新が必要となる可能性を 減らし、この文書の安定性を高める。 1 文字のサブタグは、[RFC5226] で定義された "IETF Review" ポリシーを使用して IANA によって割り当てられる。このポリシーでは RFC の策定が必要であり、その RFC はサブタグを保守するための 名称、目的、プロセス、および手続きを定義しなければならない。 保守または登録機関について、名称、連絡先電子メール、 議論用リストの電子メール、およびレジストリの URL を含め、 RFC 内で明確に示さなければならない。RFC は次の各項目を 規定または含めなければならない。 o 仕様は、その作成を規定するこの文書の具体的な版または 改訂を参照しなければならず、この文書のこのセクションを 参照しなければならない。 o 仕様およびその仕様によって定義されるすべてのサブタグは、 この文書で定義されるタグおよびサブタグの形成に関する ABNF およびその他の規則に従わなければならない。特に、 Phillips & Davis ベスト・カレント・プラクティス [49ページ]
RFC 5646 言語タグ 2009年9月 大文字と小文字に意味がないこと、およびサブタグの長さが 8 文字を超えてはならないことを規定しなければならない。 o 仕様は正規表現形式を規定しなければならない。 o 有効なサブタグの仕様は、インターネット上で無償で 利用可能でなければならない。 o 仕様はパブリックドメインであるか、IETF が受け入れ可能で、 RFC 内で規定されたロイヤリティフリーのライセンスによって 利用可能でなければならない。 o 仕様にはバージョンを付けなければならず、仕様の各版には 番号と日付を付し、安定していなければならない。 o 仕様は安定していなければならない。すなわち、仕様によって 一度定義された拡張サブタグは、撤回されたり、意味が実質的に 変更されたりしてはならない。 o 仕様は、RFC として公開された際に拡張を登録するために使用する、 このセクション（以下）に再掲された登録フォームを、 独立したセクションとして含めなければならない。 o 連絡先情報および仕様の URL に変更があった場合、 IANA に通知しなければならない。 IANA は、割り当て済みの 1 文字 (singleton) サブタグのレジストリを 保守する。このレジストリは、セクション 3.1.1 の ABNF で説明される record-jar 形式を使用しなければならない。拡張が RFC として 公開された際、RFC で定義された保守機関は、この登録フォームを <iesg@ietf.org> に転送しなければならず、IESG はその要求を <iana@iana.org> に転送しなければならない。拡張の保守機関は、 内容が変更されるたびに、件名を "LANGUAGE TAG EXTENSION UPDATE" として、更新されたレコードの完全なコピーを <iana@iana.org> に 送信することで、レコードの正確性を維持しなければならない。 これらの更新では、'Comments'、'Contact_Email'、'Mailing_List'、 および 'URL' フィールドだけを変更してもよい。 このレコードまたは対応するレジストリを保守しなかった場合、 あるいはこの文書のこのセクションで課されるその他の条件を 満たさなかった場合、他の IETF の決定と同じ規則に基づいて IESG [RFC2028] に異議申し立てしてもよく （[RFC2026] を参照）、その結果、拡張を保守する権限が IESG によって 撤回または再割り当てされる場合がある。 Phillips & Davis ベスト・カレント・プラクティス [50ページ]
RFC 5646 言語タグ 2009年9月 %% Identifier: Description: Comments: Added: RFC: Authority: Contact_Email: Mailing_List: URL: %% 図 6: 言語タグ拡張レジストリ内のレコード形式 'Identifier' には、拡張に割り当てられた 1 文字のサブタグ (singleton) が含まれる。拡張を定義するために提出される Internet-Draft は、使用する文字または数字を指定すべきであるが、 IESG は RFC の承認時に割り当てを変更してもよい。 'Description' には、拡張の名称と説明が含まれる。 'Comments' は OPTIONAL フィールドであり、拡張についてより広い 説明を含めてもよい。 'Added' には、拡張の RFC が公開された日付が [RFC3339] で 規定される "full-date" 形式で含まれる。たとえば、2004-06-28 は グレゴリオ暦の 2004 年 6 月 28 日を表す。 'RFC' には、拡張に割り当てられた RFC 番号が含まれる。 'Authority' には、拡張の保守機関の名称が含まれる。 'Contact_Email' には、保守機関への連絡に使用する 電子メールアドレスが含まれる。 'Mailing_List' には、保守機関が使用するメーリングリストの URL または購読用電子メールアドレスが含まれる。 'URL' には、この拡張のレジストリの URL が含まれる。 Internet-Draft が上記の条件を満たしているかどうかの判断、および そのような権限を付与または留保する決定は IESG のみに委ねられ、 RFC プロセスに関連する通常のレビューおよび異議申し立て手続きの 対象となる。 拡張の作成者には、多くの処理系（大多数の整形式処理系を含む）が、 拡張サブタグの順序に内在する特別な関係 Phillips & Davis ベスト・カレント・プラクティス [51ページ]
RFC 5646 言語タグ 2009年9月 または意味を認識しないことが強く注意喚起される。拡張の作成者は、 照合を妨げる、または拡張が使用される一般的なプロトコルに 存在する場合がある長さ制限を妨げるような、サブタグ間の関係や 正規化機構を避けるべきである。特に、アプリケーションは照合時、 または制限された長さに収めるためにサブタグを切り詰める場合がある。 そのため、最も重要な情報を最も重要な（最も左側の）サブタグに 置き、仕様が切り詰められたサブタグを適切に処理することが推奨される。 言語タグを特定の既知のプロトコルで使用する場合、そのプロトコルが サポートしていない拡張を言語タグに含めないことが推奨される。 さらに、一部のプロトコルでは、言語タグを保存または転送するために 使用される文字列の長さに上限が課される場合があることに注意されたい。 3.8. 言語サブタグレジストリの更新 この文書の採用後、IANA 言語サブタグレジストリには、言語タグ内で 有効なサブタグの完全な集合を含めるための更新が必要となった。 [RFC5645] は、この更新を作成するために使用された手続きを説明する。 この文書が採用された時点で [RFC4646] に定義された規則に 基づいて進行中の登録は、この文書に含まれる規則に基づいて 完了しなければならない。 3.9. サブタグレジストリの適用可能性 Language Subtag Registry は、この文書に記載された規則に従って 言語タグを構築するために使用されるデータ要素の出典である。 言語タグは、テキストだけでなく、動画や音声など大多数の メディア形式を含む、さまざまなコンテンツの言語的属性を示すために 設計されている。また、さまざまなプロトコルおよび API における 言語およびロケールネゴシエーションの基礎も形成する。 したがって、このレジストリは何らかの形で言語識別を必要とする 多くのアプリケーションに適用できるが、次の制限がある。 o 言語選択ユーザーインターフェイスを作成する際の唯一の データソースとして設計されているわけではない。たとえば、 レジストリにはサブタグの説明またはサブタグから構成される タグの翻訳は含まれない。レジストリに基づくローカライズ済み データの出典は一般に利用可能であり、特に [CLDR] がある。 また、どのサブタグの組み合わせが特に有用または関連性が高いかも レジストリには示されない。 Phillips & Davis ベスト・カレント・プラクティス [52ページ]
RFC 5646 言語タグ 2009年9月 o 異なる言語間の関係を示す情報を提供しない。たとえば、 言語タグを階層的、地域的、またはその他の組織モデルに基づいて 選択するユーザーインターフェイスで使用できるような情報である。 o 言語を構成するものという概念は厳密ではないため、異なる 言語タグ間で起こり得る重複についての情報を提供しない。 同じ一つのコンテンツについて、複数の異なる言語タグが 妥当な選択肢となる場合がある。 o 言語ネゴシエーションを行う際の適切なフォールバック選択に 関する情報を含まない。適切なフォールバック言語は、指定された 言語と系統的に無関係である場合がある。ある言語が別の言語の フォールバックとして頻繁に使用されるという事実は通常、 地理、歴史、文化などの外部要因によるものであり、これらの要因は すべての場合に適用できるとは限らない。たとえば、 ブルトン語（フランス北西部で使用されるケルト語派の言語）を 使用する大多数の人は、ブルトン語が利用できない場合には、 おそらくフランス語（ロマンス語派の言語）で提供されることを 望むだろう。 4. 言語タグの形成と処理 このセクションでは、レジストリ内の情報をタグ構文とともに使用して、 言語タグを選択、形成、および処理する方法を扱う。 4.1. 言語タグの選択 言語タグを形成する際の基本原則は、「コンテンツに適切にタグを 付ける」ことである。同じコンテンツについて複数のタグが選択可能な 場合がある。どのタグを使用するかは対象となるコンテンツと アプリケーションによって異なり、タグの選択にはある程度の判断が 必要になる場合がある。 同じ言語を表すために同じ言語タグを一貫して使用することが、 相互運用性に最も有益である。ここでの規則を適用できない要件を アプリケーションが持つ場合、そのアプリケーションは相互運用性を 損なう危険がある。ユーザーが独自の言語タグ選択規則を定義しない ことが強く推奨される。 この文書を規範的に参照しながら、このセクションに示すものとは 異なる規則を適用する規格、プロトコル、およびアプリケーションは、 言語タグの選択がここに示された指針とどのように異なるかを 規定しなければならない。 一貫した後方互換性を確保するため、この文書には、言語タグを構成する サブタグの定義に使用される規格で起こり得る不安定性に対応するための 複数の規定が含まれている。 Phillips & Davis ベスト・カレント・プラクティス [53ページ]
RFC 5646 言語タグ 2009年9月 これらの規定により、有効な言語タグが無効になることはなく、 将来、言語タグの範囲が狭くなることもない（広くなる場合はある）。 特定のアプリケーションまたはコンテンツ項目に最も適切な言語タグは 時間とともに変化する可能性があるが、一度適用されたタグ自体が 無効になったり、その意味が完全に変化したりすることはない。 サブタグは、タグに有用な区別情報を追加する場合にのみ 使用すべきである。余分なサブタグは、言語タグの意味、理解、 および処理を妨げる。特に、ユーザーおよび実装は、レジストリ内の 'Prefix' および 'Suppress-Script' フィールド （セクション 3.1 で定義）に従うべきである。これらのフィールドは、 特定の追加サブタグを言語タグ内でいつ使用すべきか、 または避けるべきかについて指針を提供する。 言語タグを形成するために使用するサブタグの選択は、 次の指針に従うべきである。 1. 可能な限り正確なタグを使用するが、正当化される以上に 詳細にしてはならない。アプリケーション内でコンテンツを 区別するために重要でないサブタグの使用は避ける。 * たとえば、ドイツ語で書かれた電子メールにタグを付ける場合、 'de' で十分である可能性があり、"de-CH-1996" はその用途には おそらく不必要に詳細である。 * 一部のサブタグシーケンスは、一般ユーザーが予想する言語を 表さない場合があることに注意されたい。たとえば、 スイスドイツ語 (Schweizerdeutsch) は "de-CH" ではなく "gsw-CH" で表される。後者は、スイス ('CH') で使用される ドイツ語 ('de')、別名スイス標準ドイツ語 (Schweizer Hochdeutsch) を表す。どちらも実在する言語であり、 両者を区別することがアプリケーションにとって重要な場合がある。 2. 文字体系がタグに何らかの区別情報を追加しない限り、 言語タグを形成するために文字体系サブタグを使用すべきではない。 文字体系サブタグは [RFC4646] で初めて正式に定義された。 これらの使用は、[RFC1766] または [RFC3066]（これらは この文書によって廃止される）の実装における照合および サブタグ識別に影響を与える可能性がある。これらのサブタグは 主言語サブタグと地域サブタグの間に現れるためである。 一部のアプリケーションでは、特定の文脈で一貫して使用される 限り、言語タグ内で文字体系サブタグを使用することが有益となる。 文字体系サブタグは、書記されないコンテンツ（音声録音など）には 決して適さない。レジストリ内の主言語または拡張言語レコードにある 'Suppress-Script' フィールドは、大多数のアプリケーションで 区別情報を追加しない文字体系サブタグを示す。このフィールドは Phillips & Davis ベスト・カレント・プラクティス [54ページ]
RFC 5646 言語タグ 2009年9月 特定の主言語サブタグとともに文字体系サブタグを 含めるべきでない場合を定義する。 たとえば、実装が Basic Filtering [RFC4647] （元は [RFC2616] のセクション 14.4 に記載）を使用して コンテンツを選択し、ユーザーが言語範囲 "en-US" を要求した場合、 "en-Latn-US" とラベル付けされたコンテンツは要求に一致せず、 したがって選択されない。そのため、文字体系サブタグが通常 いつ使用され、いつ使用すべきでないかを知ることが重要である。 例: * サブタグ 'Latn' は主言語 'en' とともに使用すべきではない。 ほぼすべての英語文書がラテン文字で記述されており、 区別情報を何も追加しないためである。ただし、ある文書が、 ラテン文字と点字 ('Brai') など別の文字体系を混在させて 英語で記述されている場合、スタイルシートの適用など、 コンテンツ選択を支援するために両方の文字体系を示すことが 適切である場合がある。 * 書記されないコンテンツ（人間の発話の録音など）に ラベルを付ける場合、その言語が通常複数の文字体系で 書かれるとしても、文字体系サブタグを使用すべきではない。 したがって、映画の字幕にはタグ "uz-Arab" （ウズベク語、アラビア文字）を使用する場合があるが、 同じ言語の音声トラックには単に "uz" とタグ付けする。 （コンテンツが書記されていない場合にはタグ "uz-Zxxx" も 使用できる。サブタグ 'Zxxx' は「書記されない文書のコード」を 表すためである。） 3. タグまたはサブタグのレジストリエントリに 'Preferred-Value' フィールドがある場合、そのフィールドの値を、推奨値が現れる タグまたはサブタグより優先して、言語タグを形成するために 使用すべきである。 * たとえば、ロジバンには旧来のタグ "art-lojban" より 'jbo' を優先して使用する。 4. 言語集合のサブタグより、個別言語のサブタグまたは サブタグシーケンスを優先して使用する。「言語集合」とは、 共通の祖先から派生した、同じ地理的地域で話されている、 またはその他の形で関連する言語のグループである。 特定の言語集合には [ISO639-5] によってコードが割り当てられており （これら [ISO639-5] コードの一部は [ISO639-2] でも集合として 定義されている）、これらのコードはレジストリに主言語サブタグとして 含まれる。レジストリ内の言語集合のサブタグには、値が 'collection' の 'Scope' フィールドがある。言語集合のサブタグは Phillips & Davis ベスト・カレント・プラクティス [55ページ]
RFC 5646 言語タグ 2009年9月 'mul' や 'und'（以下を参照）のような、より具体性の低い代替手段 より常に優先され、より具体的な言語情報が利用できない場合には 言語集合を表すサブタグを使用してもよい。ただし、大多数の ユーザーおよび実装は、その集合と個別言語との関係を認識していない。 さらに、集合内の個別言語間の関係は明確には定義されておらず、 特に、それらの言語は通常相互理解可能ではない。 サブタグが異なるため、集合に対する要求では通常、その集合内に 含まれる個別言語のサブタグでタグ付けされた項目ではなく、 集合のサブタグでタグ付けされた項目だけが得られる。 * たとえば、集合は包含的に解釈されるため、サブタグ 'gem' （ゲルマン諸語）は、"en"（英語）、"de"（ドイツ語）、 または "gsw"（スイスドイツ語、アレマン語）でタグ付けした方が 適切なコンテンツに使用することもできるが、使用すべきではない。 'gem' はこれらすべて（およびその他）の言語をまとめているが、 大多数の実装は 'gem' を個別言語と照合しないため、 このサブタグを使用しても望ましい結果は得られない。 5. [ISO639-2] は、言語タグを選択する際に追加の注意を必要とする、 サブタグレジストリに含まれる複数のコードを定義している。 これらの大多数の場合、言語タグを省略することが許可されているなら、 これらのコードを使用するより省略する方が望ましい。 追加情報がアプリケーションに何らかの価値を伝える場合を除き、 言語タグにこれらのサブタグを prefix として組み込むべきではない。 * 'mul' (Multiple) 主言語サブタグは、複数の言語による コンテンツを識別する。代わりに言語の一覧または各コンテンツ 要素に個別のタグを使用できる場合、このサブタグを 使用すべきではない。たとえば、'Content-Language' ヘッダー [RFC3282] では、単一の言語タグだけでなく、 言語の一覧を使用できる。 * 'und' (Undetermined) 主言語サブタグは、言語が確定していない 言語的コンテンツを識別する。このサブタグは、言語タグが 必須であり、言語情報が利用できない、または確定できない場合を 除き使用すべきではない。（許可される場合には）言語タグを 省略する方が望ましい。'und' サブタグは、言語タグの指定を 必須とするプロトコル、または主言語サブタグが必要な場合 （"und-Latn" など）に有用な場合がある。'und' サブタグは、 特定の状況で言語タグを照合する場合にも有用なことがある。 Phillips & Davis ベスト・カレント・プラクティス [56ページ]
RFC 5646 言語タグ 2009年9月 * 'zxx' (Non-Linguistic, Not Applicable) 主言語サブタグは、 言語による分類が不適切または適用されないコンテンツを 識別する。例として、器楽または電子音楽、非言語音だけで 構成される音声録音、ナレーション、会話、印刷されたタイトル、 または字幕のない視聴覚資料、機械語または文字コードから 構成される機械可読データファイル、プログラムのソースコード などが挙げられる。 * 'mis' (Uncoded) 主言語サブタグは、言語は判明しているが、 現在対応するサブタグが存在しないコンテンツを識別する。 このサブタグは使用すべきではない。将来他のコードが追加されると その適用が無効になる可能性があるため、本質的に不安定であり、 BCP 47 の安定性目標と互換性がない。常に他のサブタグを 使用する方が望ましい。すなわち、'und'、または （事前の合意がある場合）私的利用サブタグを使用する。 6. 変種サブタグは控えめに、正しい順序で使用する。 大多数の変種サブタグは、レジストリ内に一つ以上の 'Prefix' フィールドを持ち、それらと組み合わせることが適切なサブタグの 一覧を表す。変種は、これらの 'Prefix' フィールドの一つに 現れるサブタグとのみ使用すべきである。ある変種が、その 'Prefix' フィールドの一つに第 2 の変種を列挙している場合、 両方が現れる言語タグでは、第 1 の変種は第 2 の変種の直後に 現れるべきである。汎用変種（'Prefix' フィールドをまったく 持たないもの）は、その他すべての変種サブタグの後に 現れるべきである。残りの変種は、最も重要なサブタグを先頭に 置いて順序付ける。どのサブタグも特に重要でない場合、 または関係を判断できない場合は、サブタグをアルファベット順に 並べる。変種は非常に専門的であるため、多数を一緒に使用すると、 一般にタグの範囲が狭くなりすぎ、得られる追加の精度を 相殺してしまう。サブタグを別の順序にすると、相互運用性だけでなく、 タグ全体の解釈も妨げられる。 例: * タグ "en-scotland-fonipa" （英語、スコットランド方言、IPA 音声転写）は正しい順序である。 'scotland' は "en" の 'Prefix' を持つ一方、 'fonipa' には 'Prefix' フィールドがないためである。 * タグ "sl-IT-rozaj-biske-1994" は正しい順序である。 'rozaj' は唯一の 'Prefix' として "sl" を列挙し、 'biske' は唯一の 'Prefix' として "sl-rozaj" を列挙する。 サブタグ '1994' は複数の prefix を持ち、 Phillips & Davis ベスト・カレント・プラクティス [57ページ]
RFC 5646 言語タグ 2009年9月 その中には "sl-rozaj" も含まれる。しかし、その 'Prefix' フィールドの一つが "sl-rozaj-biske" であるため、 'rozaj' と 'biske' の両方の後に置かれる。 7. 旧来のタグ "i-default" (Default Language) は、 [RFC2277] の必要を満たすために、もともと [RFC1766] に 従って登録された。これは特定の言語を示すためには使用されず、 ユーザーの言語設定を確定できない場合に使用される状態または コンテンツを識別するために使用される。デフォルト言語の コンテンツをその特定タグでラベル付けすることを要求する アプリケーションまたはプロトコルにおいて、デフォルト コンテンツをラベル付けする手段として以外には使用すべきではない。 また、デフォルト言語のコンテンツが返されていることを識別するために、 アプリケーションまたはプロトコルが使用してもよい。 4.1.1. 包含言語へのタグ付け レジストリ内の一部の主言語レコードには、各 "encompassed language" からそのマクロ言語への対応付けを含む 'Macrolanguage' フィールド（セクション 3.1.10）がある。'Macrolanguage' の対応付けは、 包含言語とそのマクロ言語との関係が何であるかを定義せず、 同じマクロ言語に包含される言語同士がどのように関係するかも 定義しない。同じマクロ言語に包含される二つの異なる言語は、 たとえばフランス語とスペイン語以上に互いに異なる場合がある。 中国語 ('zh') やアラビア語 ('ar') など、いくつかの特定の マクロ言語は異なる扱いを受ける。セクション 4.1.2 を参照されたい。 マクロ言語の主言語サブタグまたは包含言語のサブタグのどちらを 使用してもよいが、より具体的な包含言語サブタグを使用して 言語タグを形成すべきである。たとえば、プレーンズ・クリー語には 'cr'（クリー語）ではなく 'crk' を使用してタグ付けすることなどを 意味する。 各マクロ言語サブタグの範囲は、定義上、そのすべての包含言語を 含む。包含言語間の関係はさまざまであるため、ユーザーは マクロ言語サブタグが特定の包含言語を意味すると仮定することも、 任意の二つの包含言語が相互理解可能またはその他の意味で 交換可能であると仮定することもできない。 アプリケーションは、照合または言語ネゴシエーションを改善するために マクロ言語情報を使用してもよい。たとえば、'sr' （セルビア語）と 'hr'（クロアチア語）がマクロ言語を共有するという 情報は、たとえば 'sr'（セルビア語）と 'ma'（マケドニア語）との 関係よりも、これらの言語間の関係が近いことを表す。ただし、 この関係は保証されず、排他的でもない。たとえば、ルーマニア語 ('ro') と Phillips & Davis ベスト・カレント・プラクティス [58ページ]
RFC 5646 言語タグ 2009年9月 モルダビア語 ('mo') はマクロ言語を共有しないが、 マクロ言語を共有する広東語 ('yue') と呉語 ('wuu') よりも はるかに密接に関連している。 4.1.2. 拡張言語サブタグの使用 この文書の採用以前に使用されていた言語タグ形式に対応するため、 言語タグには特別な互換性機構、すなわち拡張言語サブタグがある。 選択された言語には、主言語サブタグと拡張言語サブタグの両方が 提供されている。これには、一般にマクロ言語と同義とされる 特定の支配的変種を持つ、マレー語 ('ms') やウズベク語 ('uz') などのマクロ言語が含まれる。中国語 ('zh') やアラビア語 ('ar') のマクロ言語、各種手話 ('sgn') などの他の言語では、伝統的に 主言語サブタグを、場合によっては各種地域サブタグと組み合わせたり、 登録済みの旧来タグの一部として使用したりして、その言語を示してきた。 この文書の採用に伴い、これらの多様な言語族またはグループに 含まれる言語を識別するために、特定の ISO 639-3 サブタグが 利用可能となった。これにより、以前は存在しなかった言語タグの 選択肢が生じる。 o 各包含言語のサブタグを主言語サブタグとして使用すべきである。 たとえば、官話による文書には "zh"（中国語）よりも "cmn"（官話のサブタグ）を優先してタグ付けする。 o 互換性が望ましい、または必要な場合、包含サブタグを 拡張言語サブタグとして使用してもよい。たとえば、官話による 文書には "cmn" または "zh" の代わりに "zh-cmn" と タグ付けすることができる。 o より具体的な包含言語サブタグの代わりに、マクロ言語または prefix となるサブタグを使用してタグを形成してもよい。 すなわち、"zh-HK" や "sgn-RU" のようなタグも引き続き有効である。 中国語 ('zh') は、この点を説明する有用な例である。過去には、 各種コンテンツで 'zh' サブタグから始まるタグが使用され、 地域コード、私的利用シーケンス、または登録済みの旧来値に、 アプリケーション固有の意味が関連付けられていた。これは歴史的に、 言語タグを形成するために利用可能だったのがマクロ言語サブタグ 'zh' だけだったためである。しかし、中国語サブタグ 'zh' に 包含される言語は、主として話し言葉では相互理解可能ではなく、 これらの言語の書記形式も、形式および用法に大きな違いを示す。 Phillips & Davis ベスト・カレント・プラクティス [59ページ]
RFC 5646 言語タグ 2009年9月 互換性を提供するため、'zh' サブタグに包含される中国語の各言語は、 主言語サブタグとしても拡張言語サブタグとしてもレジストリに 登録されている。たとえば、広東語の ISO 639-3 コードは 'yue' である。 広東語のコンテンツには、歴史的には "zh-HK" のようなタグが 使用されていた可能性がある（広東語は香港で広く話されているため）。 ただし、このタグが実際に意味するのは、香港で使用されるあらゆる 種類の中国語である。ISO 639-3 コードがレジストリで利用可能に なったことで、広東語のコンテンツには 'yue' サブタグを使用して 直接タグ付けできる。タグ "yue-HK"（広東語、香港）のように、 これを主言語サブタグとして使用できる。または、タグ "zh-yue-Hant"（中国語、広東語、繁体字）のように、'zh' とともに 拡張言語サブタグを使用することもできる。 上述したように、アプリケーションは、より具体的な包含言語サブタグを 使用する代わりに、マクロ言語サブタグを使用してタグを形成することを 選択できる。たとえば、'zh'（中国語）サブタグを含むタグを使用した 大量のデータをすでに持つアプリケーションは、そのコンテンツを 'cmn'（官話）、'yue'（広東語）、'wuu'（呉語）などでより正確に タグ付けできる場合でも、新しいデータに対してこのより一般的な サブタグを引き続き使用する場合がある。同様に、'ar'（アラビア語） サブタグで始まるタグをすでに使用しているアプリケーションは、 'arb'（標準アラビア語）でより正確にタグ付けできる新しいデータに 対しても、このより一般的なサブタグを引き続き使用する場合がある。 場合によっては、包含言語に対して RFC 3066 時代にタグが 登録されていた。この文書の採用時に、まだ非推奨になっておらず、 また冗長にもなっていなかったこれらの旧来のタグは、レジストリで 非推奨とされた。旧来の値として、これらは引き続き使用可能な 有効な値であり、一部のコンテンツまたはアプリケーションで 使用される可能性がある。他の旧来のタグと同様、実装は旧来の タグを、この文書が推奨する包含言語サブタグの同等値と関連付けられない 場合があるため、比較のためにタグを正規化することが推奨される。 その例には、タグ "zh-hakka"（客家語）や "zh-guoyu" （官話または標準中国語）がある。 手話は言語的な系統ではなく、コミュニケーションの様式を共有する。 独立して発達した多数の手話が存在し、サブタグ 'sgn' は手話が 存在することだけを示す。また、多数の手話について RFC 3066 時代に旧来のタグが登録されていた。たとえば、 旧来のタグ "sgn-US" は、米国を参照することなく、特に 「アメリカ手話」を表すために登録された。これは現在も有効だが 非推奨である。アメリカ手話の文書には "ase" または "sgn-ase" のいずれかでラベル付けできる（'ase' サブタグは 「アメリカ手話」と呼ばれる言語を表す）。 Phillips & Davis ベスト・カレント・プラクティス [60ページ]
RFC 5646 言語タグ 2009年9月 4.2. 言語タグの意味 言語タグの意味は、そのタグに含まれるサブタグの意味と関連している。 各サブタグは、それに関連するコンテンツについて期待し得る 一定の範囲を示唆するが、それを保証するものではない。 たとえば、'Arab'（アラビア文字）のような文字体系サブタグを 使用しても、そのコンテンツがアラビア文字だけを含むことを 意味するわけではない。これは、対象となる言語が主として アラビア文字で記述されることを意味する。したがって、言語タグと そのサブタグは非常に広範な変異を包含しながらも、個々の状況では 適切であり得る。 タグの有効性は、その有用性を決定する唯一の要因ではない。 すべての有効なタグには意味があるが、現実世界の言語使用を 何も表していない場合がある。これは、サブタグを自由に組み合わせられる システムでは避けられない。たとえば、"ar-Cyrl-CO" （アラビア語、キリル文字、コロンビアで使用）や "tlh- Kore-AQ-fonipa"（クリンゴン語、ハングル、南極で使用、 IPA 音声転写）のようなタグはいずれも有効だが、有用な 言語属性の組み合わせを表す可能性は低い。 あるタグの意味は、それが現れる文脈には依存しない。ただし、 タグの意味と、そのタグが適用される情報オブジェクトとの関係は 変化し得る。 o 単一の情報オブジェクトについて、関連付けられた言語タグは、 オブジェクト全体を完全に理解するために必要な言語の集合として 解釈される場合がある。例: プレーンテキスト文書。 o 情報オブジェクトの集合について、関連付けられた言語タグは、 その集合の構成要素内で使用される言語の集合として扱われる 場合がある。例: 文書ストアおよびライブラリ。 o 代替手段を提供することを目的とする情報オブジェクトでは、 関連付けられた言語タグは、コンテンツが複数の言語で提供されており、 その言語または言語群を見つけるために各代替項目を確認する 必要があることを示すヒントと見なせる。この場合、複数のタグが 存在しても、文書を完全に理解するために複数言語を理解する 必要があることを意味するとは限らない。例: MIME multipart/ alternative [RFC2046]。 o HTML や XML のようなマークアップ言語では、マークアップ構造に よって識別される文書の各部分（文書全体を含む）に言語情報を 追加できる。たとえば、ドイツ語の文書内に <span lang="fr">C'est la vie.</span> と記述できる。 その場合、ドイツ語を話すユーザーは、フランス語- Phillips & Davis ベスト・カレント・プラクティス [61ページ]
RFC 5646 言語タグ 2009年9月 ドイツ語辞書にアクセスして、マークされた部分の意味を確認できる。 ユーザーが音声合成インターフェイスを通じてその文書を聞いている 場合、この形式を使用して、合成器に対し、不適切なドイツ語の 規則ではなく、フランス語のテキスト読み上げ発音規則をその テキスト範囲に適切に適用するよう通知できる。 o 対象読者を識別できるマークアップ言語および文書形式では、 言語タグによって、その文書に適した対象読者を示すことができる。 たとえば、前の箇条書きで説明した同じ HTML 文書に、 HTTP ヘッダー "Content-Language: de" を付けて、そのファイルの 想定読者がドイツ語話者であることを示すことができる （その中にフランス語であると識別された 3 語が現れていてもよい）。 o システムおよび API では、言語タグはロケール識別子の大多数の 実装の基礎を形成する。たとえば、Unicode の CLDR (Common Locale Data Repository)（UTS #35 [UTS35] を参照） プロジェクトを参照されたい。 言語タグは、類似するサブタグシーケンスを含む場合に関連している。 たとえば、言語タグ B が言語タグ A を prefix として含む場合、 B は通常、A より「狭い」または「より具体的」である。 したがって、"zh-Hant-TW" は "zh-Hant" より具体的である。 この関係はすべての場合に保証されるわけではない。特に、 同じサブタグシーケンスで始まる言語が相互理解可能であることは 保証されないが、そうである場合もある。たとえば、タグ "az" は "az-Latn"（ラテン文字で記述されたアゼルバイジャン語）と "az-Cyrl"（キリル文字で記述されたアゼルバイジャン語）の両方と prefix を共有する。一方の文字体系に習熟した人が、もう一方を 読めない場合がある。ただし、言語的内容（たとえば、両方の テキストを読み上げた場合に聞こえる内容）は同一である場合もある。 "az" とタグ付けされたコンテンツは、おそらく一つの文字体系だけで 記述されているため、もう一方の文字体系に慣れた読者には 理解できない可能性がある。 同様に、すべてのサブタグが言語上の実際の区別を指定するわけではない。 たとえば、タグ "en-US" と "en-CA" は、おおよそそれぞれ 米国とカナダに一般的に特徴的と考えられる特徴を持つ英語を意味する。 これらは、米国内の任意の地点とカナダ内の任意の地点との間に 重大な方言境界が存在することを意味しない。また、特定の地域 サブタグが、その地域内に言語上の区別が存在しないことを 意味するわけでもない。 Phillips & Davis ベスト・カレント・プラクティス [62ページ]
RFC 5646 言語タグ 2009年9月 4.3. 言語の一覧 一部のアプリケーションでは、一つのコンテンツ項目を複数の言語タグと 関連付けることが最適な場合がある。このような使用例には 次のものがある。 o 複数の異なる変種を含むコンテンツ項目。複数の選択肢が適切な 場合に、特定のコンテンツ項目に適した対象読者を示すために 使用されることが多い。その例には次のものがある。 * 映画タイトルの適切な対象読者に関するメタデータ。 たとえば、DVD では個別の音声トラックに 'de'（ドイツ語）、 'fr'（フランス語）、'es'（スペイン語）とラベル付けできるが、 タイトル全体では対象読者として "de, fr, es" を列挙する。 * フランス語／英語、英語／フランス語辞書に "en" と "fr" の 両方をタグ付けし、フランス語と英語の両方に等しく適用される ことを示す。 * ラテン語やギリシャ語の古典作品で一般的に行われる、 文書の左右対訳または行間訳。 o 単一の言語を含むが、複数レベルの具体性を必要とする コンテンツ項目。たとえば、図書館では、違いを理解できる、 またはより限定的にコンテンツを選択する必要がある利用者のために、 特定の作品をノルウェー語 ('no') とニーノシュク ('nn') の 両方として分類したい場合がある。 4.4. 長さに関する考慮事項 言語タグのサイズについて定義された上限はない。歴史的には 大多数の言語タグは、言語サブタグと地域サブタグを合わせて 最大 6 文字程度で構成されていたが、より大きなタグも常に可能であり、 実際に使用されてきた。 言語タグ構文にも、この文書のその他の要件にも、言語タグ内の サブタグ数（したがってタグのサイズ）に固定された上限はない。 言語タグ構文は、特定の言語によっては、一部のアプリケーションで 言語を完全に識別するためにより多くのサブタグ （したがってより長いタグ）が必要になる場合があることを示している。 したがって、長い、または複雑なサブタグシーケンスも想定できる。 Phillips & Davis ベスト・カレント・プラクティス [63ページ]
RFC 5646 言語タグ 2009年9月 4.4.1. 制限されたバッファサイズでの処理 一部のアプリケーションおよびプロトコルでは、固定された バッファサイズを割り当てるか、その他の方法で言語タグの長さを 制限せざるを得ない。適合する実装または仕様は、指定された長さを 超える言語タグの保存をサポートしないことを選択してもよい。 そのような制限は明確に文書化すべきであり、その文書には、 より長いタグに何が起こるか（たとえば、エラー値を生成するのか、 言語タグを切り詰めるのか）を含めるべきである。制限値が何であるかを 何も示さず、任意の上限でタグを切り詰めることを許可する プロトコルは、タグの意味を大幅に変えることで問題を引き起こす 可能性がある。 実際には、大多数の言語タグは数個を超えるサブタグを必要とせず、 合理的なサイズのバッファ制限に近づくことはない。 セクション 4.1 を参照されたい。 一部の仕様またはプロトコルにはタグ長の制限があるが、 固定長の制限ではない。たとえば、[RFC2231] には明示的な 長さ制限がない。言語タグに利用可能な長さは、他のヘッダー構成要素 （charset 名など）の長さと [RFC2047] の 76 文字制限の組み合わせに よって制約される。したがって、この「制限」は 50 文字以上である 場合もあるが、かなり小さくなる可能性もある。 バッファ制限を設定する際の考慮事項は次のとおりである。 実装は、タグの意味を意図的に変更する場合、または保存もしくは 転送のためにプロトコルが指定した制限付きバッファサイズにタグが 収まらない場合を除き、言語タグを切り詰めるべきではない。 切り詰めはタグの意味を変更するため、実装はタグを切り詰める際に ユーザーへ警告すべきである。 空間に制約があるが固定上限を持たないプロトコルまたは仕様の 実装は、切り詰めるよりも可能な限り長いタグを使用すべきである。 言語タグについて制限されたバッファサイズを指定するプロトコル または仕様は、少なくとも 35 文字の言語タグを許容しなければならない。 [RFC4646] は 'extlang' 生成規則の 3 要素すべてを含めていたため、 最小フィールドサイズとして 42 文字を推奨していたことに 注意されたい。現在、そのうち二つは恒久的に予約されているため、 最大長 8 文字の登録済み主言語サブタグの方が、最長の language-extlang の組み合わせより長くなる。一般的に Phillips & Davis ベスト・カレント・プラクティス [64ページ]
RFC 5646 言語タグ 2009年9月 拡張または私的利用サブタグを使用するプロトコルまたは仕様では、 より長い「最小バッファ」サイズを確保または推奨することが 望ましい場合がある。 次の図は、35 文字という推奨値がどのように導かれたかを示す。 language = 8 ; 許可される登録値の最長 ; primary+extlang より長い ; これは 7 文字を必要とする script = 5 ; 抑制されない場合: セクション 4.1 を参照 region = 4 ; UN M.49 数値地域コード ; ISO 3166-1 コードは 3 文字を必要とする variant1 = 9 ; prefix として 'language' を必要とする variant2 = 9 ; 非常にまれであり、 ; prefix として 'language-variant1' を必要とする total = 35 文字 図 7: タグ長制限の導出 4.4.2. 言語タグの切り詰め 言語タグを切り詰めるとタグの意味が変わるため、避けるべきである。 ただし、制限されたバッファサイズのために言語タグの切り詰めが 必要となる場合もある。このような切り詰めでは、サブタグを途中で 切断したり、無効なタグ（たとえば "-" 文字で終わるもの）を 形成したりしてはならない。 これは、タグを切り詰めるアプリケーションまたはプロトコルは、 指定されたバッファに収まるだけの長さになるまで、言語タグの右側から サブタグとその前の "-" を順次削除しなければならないことを意味する。 その結果得られたタグが 1 文字のサブタグで終わる場合、 そのサブタグとその前の "-" も削除しなければならない。例: 切り詰めるタグ: zh-Latn-CN-variant1-a-extend1-x-wadegile-private1 1. zh-Latn-CN-variant1-a-extend1-x-wadegile 2. zh-Latn-CN-variant1-a-extend1 3. zh-Latn-CN-variant1 4. zh-Latn-CN 5. zh-Latn 6. zh 図 8: タグ切り詰めの例 Phillips & Davis ベスト・カレント・プラクティス [65ページ]
RFC 5646 言語タグ 2009年9月 4.5. 言語タグの正規化 特定の言語タグは多数の処理で使用される可能性があるため、 言語タグは常に正規形で作成または生成すべきである。 言語タグが 2.1 および 2.2 の規則に従って整形式であり、 IANA レジストリのデータ（セクション 3.1 を参照）を使用して、 次の各手順を順番に適用して正規化されている場合、その言語タグは 'canonical form' である。 1. 拡張シーケンスを singleton サブタグに基づき、 大文字と小文字を区別しない ASCII 順に並べる。 * たとえば、サブタグシーケンス '-a-babble' は '-b-warble' より前になる。 2. 冗長または旧来のタグに 'Preferred-Value' がある場合、 それで置き換える。 * 旧来および冗長なタグの 'Preferred-Value' の field-body は 「拡張言語範囲」[RFC4647] であり、複数のサブタグで 構成される場合がある。 * レジストリ内の 'Preferred-Value' フィールドは、 非推奨のタグから現代的な同等値への対応付けを提供する。 これらの多くは、この文書の採用前に作成された （"no-nyn" から "nn"、または "i-klingon" から "tlh" への 対応付けなど）。その他は、この文書で許可または要求される 後の登録またはレジストリへの追加の結果である （たとえば、この文書の採用時に "zh-hakka" は ISO 639-3 コード 'hak' を優先して非推奨となった）。 3. サブタグに 'Preferred-Value' がある場合、それで置き換える。 extlang の場合、'Preferred-Value' に主言語サブタグが 含まれていれば、元の主言語サブタグも置き換える。 * extlang の 'Preferred-Value' の field-body は 「拡張言語範囲」であり、通常は主言語サブタグへ対応付けられる。 たとえば、サブタグシーケンス "zh-hak"（中国語、客家語）は、 サブタグ 'hak'（客家語）に置き換えられる。 * extlang 以外のサブタグの大半は、国名または名称が変更された Region サブタグ、または ISO 639-1 に対する事務的な修正である。 Phillips & Davis ベスト・カレント・プラクティス [66ページ]
RFC 5646 言語タグ 2009年9月 正規形には 'extlang' サブタグは含まれない。extlang サブタグを 維持または復元する代替の 'extlang form' がある。この形式は、 'Prefix' サブタグの存在が照合または選択で有益と見なされる環境で 有用な場合がある（セクション 4.1.2 を参照）。 言語タグが 2.1 および 2.2 の規則に従って整形式であり、 IANA レジストリのデータを使用して次の二つの手順を順番に 適用して処理されている場合、その言語タグは 'extlang form' である。 1. まず、言語タグを上記のとおり正規形に変換する。 2. 言語タグが、extlang サブタグでもある主言語サブタグで始まる場合、 extlang の 'Prefix' を言語タグの前に付加する。 * たとえば、"hak-CN"（客家語、中国）は主言語サブタグ 'hak' を 持ち、その 'hak' には 'Prefix' 'zh'（中国語）を持つ 'extlang' レコードがある。extlang form は "zh-hak-CN" （中国語、客家語、中国）となる。 * 手順 2（prefix の前置）は、手順 1（正規化）によって 削除されたサブタグを復元する場合があることに注意されたい。 例: 言語タグ "en-a-aaa-b-ccc-bbb-x-xyz" は正規形である一方、 "en-b-ccc-bbb-a-aaa-X-xyz" は整形式であり、有効である可能性も あるが（この文書の公開時点では拡張 'a' と 'b' は定義されていない）、 正規形ではない（拡張がアルファベット順になっていない）。 例: タグ "en-BU"（ビルマで使用される英語）は有効性を維持するが、 'BU' サブタグには 'MM'（ミャンマー）への正規対応付けがあるため、 言語タグ "en-BU" は正規形ではない。 言語タグの正規化は、サブタグを処理または比較する際の大文字と 小文字の使用について何も意味しない（セクション 2.1 に記載されている）。 すべての比較は大文字と小文字を区別せずに行わなければならない。 言語タグを正規化するとき、処理系は、レジストリで使用される 大文字と小文字（セクション 2.1.1 を参照）に従って、 サブタグの大文字・小文字を正規化してもよい （すなわち、この処理は OPTIONAL である）。 Phillips & Davis ベスト・カレント・プラクティス [67ページ]
RFC 5646 言語タグ 2009年9月 タグ内に複数の変種が現れる場合、処理系は、より良い照合動作または より一貫した表示を得るために変種を並べ替えてもよい。 変種の並べ替えは、セクション 4.1 の変種順序に関する推奨事項に 従うべきである。 レジストリレコードにフィールド 'Deprecated' が現れ、 対応する 'Preferred-Value' フィールドがない場合、そのタグまたは サブタグは置換なしで非推奨となっている。これらの値は、 言語タグ内に現れる場合には正規値である。ただし、これらの値を 含むタグをユーザーが選択したり、実装が生成したりすべきではない。 拡張は、拡張内の各種サブタグ間に存在するあらゆる関係を 定義しなければならず、そのため拡張のサブタグについて代替の 正規化方式を定義してもよい。拡張は、そのサブタグの順序を どのように解釈するかを定義してもよい。たとえば、ある拡張は、 サブタグを ASCII 順に配置した場合に正規順であると定義できる。 すなわち、"en-a-ccc-bbb-aaa" ではなく "en-a-aaa-bbb-ccc" とする。別の拡張は、サブタグの順序が 意味に影響すると定義する場合がある （その場合 "en-b-ccc-bbb-aaa" は "en-b-aaa-bbb-ccc" とは 異なる値を持つ）。ただし、拡張仕様は、セクション 3.7 で 説明される一般的な処理に耐えられるよう設計すべきである。 4.6. 私的利用サブタグに関する考慮事項 私的利用サブタグは、その他すべてのサブタグと同様、 ABNF の形式および内容の制約に従わなければならない。 私的利用サブタグは、それらを使用する言語タグを使用または 交換しようとする当事者間の私的な合意の外では意味を持たない。 同じサブタグを、別個の私的な合意に基づいて異なる意味で 使用してもよい。代替手段が存在する場合には使用すべきではなく、 一般用途を目的とするコンテンツまたはプロトコルでも使用すべきではない。 私的利用サブタグは、事前の取り決めなしでは情報交換にまったく 役立たない。私的利用タグおよびそのような言語タグ内で使用される サブタグの値と意味は、この文書では定義されない。 'x' singleton によって導入される私的利用シーケンスは、 私的利用合意の外にいるユーザーまたは実装には完全に不透明である。 そのため、singleton サブタグ 'x' によって導入される私的利用 サブタグシーケンスに加え、Language Subtag Registry は、 基礎となる規格によって割り当てられた私的利用コードから派生した 私的利用の言語、文字体系、および地域サブタグを提供する。 これらのサブタグは言語タグを形成するために使用する有効な値であり、 'x' singleton の私的利用サブタグシーケンスよりも推奨される Phillips & Davis ベスト・カレント・プラクティス [68ページ]
RFC 5646 言語タグ 2009年9月 これは、言語タグ固有の構造との関連付けによって、より多くの 情報を伝えるためである。 たとえば、地域サブタグ 'AA'、'ZZ'、および 'QM'-'QZ' と 'XA'-'XZ' の範囲（ISO 3166-1 の私的利用コードに由来）は、 言語タグを形成するために使用できる。"zh-Hans-XQ" のようなタグは、 言語資料について公開された交換可能な多くの情報 （簡体字中国語であり、ある地理的地域 'XQ' に適していること）を 伝える。正確な地理的地域は私的な合意の外では不明だが、 このタグは "x-somelang" のような不透明なタグ、あるいは "zh-Hans-x-xq"（'xq' サブタグの意味が完全に不透明）よりも はるかに多くの情報を伝える。 ただし、一部の場合には、私的利用サブタグでタグ付けされた コンテンツが、不透明で私的に定義されたサブタグを使用するタグと 比べて、他のシステムと異なる、場合によっては不適切な形で 相互作用することがある。そのため、最適な方法の選択は、 対象となる特定の分野によって異なる場合がある。 5. IANA に関する考慮事項 このセクションでは、この文書で定義されるサブタグおよび拡張 レジストリを、[RFC5226] の要件に従って IANA が保守するために 必要な手続きと要件を扱う。 この文書で定義される二つのレジストリについて IANA の保守担当者に 与える影響は、新しいエントリまたは更新の頻度がわずかに増加する ことである。また IANA は、レジストリの変更および更新を通知する 新しいメーリングリスト（以下の セクション 5.1 で説明）を 作成する必要がある。 5.1. 言語サブタグレジストリ IANA は、関連文書 [RFC5645] で提供された指示および内容を使用して レジストリを更新した。更新されたレコード集合を選択するための 基準および手続きは、その文書に記載されている。更新済みの レコード集合を作成する作業は外部で実施されるため、この更新は IANA に負担を与えない。 Language Subtag Registry に関する今後の作業には、次の活動が含まれる。 o レコード全体の挿入または置換。これらのレコードは、 セクション 3.3 に記載されているように Language Subtag Reviewer が IANA 向けに事前に書式設定する。 o 登録フォームを保存し、一般公開する。 Phillips & Davis ベスト・カレント・プラクティス [69ページ]
RFC 5646 言語タグ 2009年9月 o レジストリの更新された各版を "ietf-languages-announcements@iana.org" メーリングリストで通知する。 IANA に送信される各登録フォームには、レジストリに組み込むための 単一のレコードが含まれる。フォームは Language Subtag Reviewer に よって <iana@iana.org> に送信される。件名行には、添付フォームが 新しいレコードの挿入（件名行の "INSERT" という語で示される）を 表すのか、既存レコードの置換（件名行の "MODIFY" という語で示される） を表すのかが示される。いかなる場合もレコードをレジストリから 削除することはできない。 IANA はフォームからレコードを抽出し、挿入または変更されたレコードを Language Subtag Registry の適切なセクションに配置し、 'Type' フィールドごとにレコードをグループ化する。挿入された レコードは適切なセクション内の任意の場所に配置できる。 レジストリのレコードについて、常に 'Type' ごとにグループ化される ことを除き、特定の順序で配置される保証はない。変更された レコードは、置き換えるレコードを上書きする。 レジストリ内にエントリが作成または変更されるたびに、 レジストリ先頭の 'File-Date' レコードは最新の変更日を反映するよう 更新される。日付形式は [RFC3339] の "full-date" 形式でなければならない。 日付は、その版のレジストリが IANA によって最初に公開された日付で なければならない。1 日に公開されるレジストリの版は最大一つで なければならない。また、レコードの挿入または変更を IANA に 要求する各要求にも 'File-Date' レコードが含まれ、要求内の レコードが受理された日付を示す。 更新されたレジストリファイルは UTF-8 文字エンコーディングを 使用しなければならず、IANA はレジストリファイルが正しく 符号化されていることを確認しなければならない。非 ASCII 文字は、 登録フォームを電子メールメッセージに添付するか、メール本文で 各種エンコーディングを使用して IANA に送信できる （UTF-8 が推奨される）。IANA は、更新されたレジストリを公開する前に、 不明瞭または破損した文字を Language Subtag Reviewer に確認する。 IANA はまた、各登録フォームを保存し、 http://www.iana.org から一般公開する。同じレジストリレコードに 複数の登録が関連する場合があることに注意されたい。 Language Subtag Registry に依存する開発者は、実装を更新できるよう、 レジストリの変更について通知を受けたい場合がある。 Language Subtag Registry に変更が加えられると、IANA は <ietf-languages-announcements@iana.org>（自己購読型で、 IANA だけが投稿できるリスト）に通知メッセージを送信する。 Phillips & Davis ベスト・カレント・プラクティス [70ページ]
RFC 5646 言語タグ 2009年9月 5.2. 拡張レジストリ Language Tag Extensions Registry に含められるレコードは最大 35 件であり、 したがって、このレジストリへの変更は非常にまれであると予想される。 Language Tag Extensions Registry に関する IANA の今後の作業は 二つの場合に限られる。第一に、IESG は時折、新しいレコードを このレジストリに挿入するよう要求してもよい。これらの要求には、 セクション 3.7 に記載された正確な形式で挿入するレコードを 含めなければならない。さらに、特定の拡張の保守機関から、 レコード内の連絡先情報または URL を更新する要求が時折 行われる場合がある。これらの要求には、更新済みの完全なレコードを 含めなければならない。IANA は提供された情報の妥当性を検証する 責任はなく、正しく書式設定されていることだけを確認する。 IANA は、その要求がレジストリ内のレコードに記載されている 保守機関から送られたものであることを確認するため、 合理的な措置を取るべきである。 6. セキュリティに関する考慮事項 コンテンツネゴシエーションで使用される言語タグは、 インターネット上で交換されるその他の情報と同様、 送信者の国籍を推測し、それによって監視対象となり得る者を 識別するために使用される可能性があるため、懸念の原因となる 場合がある。 これは、送信されたものはすべて受信者に見え、場合によっては 第三者にも見えるという一般的な問題の特殊な例である。 このような懸念が特定の場合に存在し得ることを認識しておくことは 有用である。 脅威の正確な大きさの評価および考えられる対策は、それぞれの アプリケーションプロトコルに委ねられる （セキュリティ上の脅威と防御に関するベスト・カレント・プラクティスの 指針については BCP 72 [RFC3552] を参照）。 特定の情報項目に関連付けられた言語タグは、そのコンテンツに 同形異字が含まれる可能性があるかどうかを判断するうえで、 まったく意味を持たない。テキストがある言語であるとタグ付けされて いること、または特定の文字体系サブタグを使用しているという事実は、 その言語タグに関連付けられた、または指定された文字体系以外の 文字を含まないことを何ら保証しない。 変種、私的利用、および拡張サブタグの数には制限がなく、 その結果、タグの長さにも制限がないため、実装はバッファ オーバーフロー攻撃に備える必要がある。バッファオーバーフローへの 防御の結果として発生する場合がある言語タグの切り詰めについては、 セクション 4.4 を参照されたい。 Phillips & Davis ベスト・カレント・プラクティス [71ページ]
RFC 5646 言語タグ 2009年9月 サービス拒否攻撃を防ぐため、アプリケーションは Language Subtag Registry または Language Tag Extensions Registry が 常にアクセス可能であることに依存すべきではない。さらに、 拡張について有効なサブタグの仕様（セクション 3.7 を参照）は インターネット上で利用可能でなければならないが、実装は それらの情報源が常にアクセス可能であることに機械的に 依存すべきではない。 この文書で規定されるレジストリは、レジストリ全体の内容を 頻繁またはリアルタイムでアクセスまたは取得する用途には適さない。 大多数のアプリケーションはレジストリデータをまったく必要としない。 その他の場合でも、レジストリの内容は時折しか変更されないため、 特定のレジストリ日付時点で言語タグを検証または正規化できれば 十分である。変更は <ietf-languages-announcements@iana.org> に 通知される。このメーリングリストは関心を持つ組織および個人向けであり、 自動ソフトウェア更新を起動するための大量購読を目的としていない。 レジストリのサイズは自動ソフトウェア更新には適していない。 Language Subtag Registry を自動更新方式に統合することを検討する 実装者には、適切に符号化された差分だけを、自身のインフラストラクチャを 通じて配布し、IANA から直接配布しないことが強く推奨される。 変更の有無は、レジストリ先頭の 'File-Date' レコードを確認するか、 完全なレジストリをダウンロードすることなく、ダウンロードに 使用されるプロトコルの機能を使用することでも容易に検出できる。 この文書の公開時点で、IANA は Language Tag Registry を HTTP 1.1 で提供している。HTTP 1.1 を使用して Language Subtag Registry のローカルコピーを更新する適切な方法は、 条件付き GET [RFC2616] を使用することである。 7. 文字集合に関する考慮事項 この文書の構文では、言語タグに、大多数の文字集合に存在する A-Z、a-z、0-9、および HYPHEN-MINUS の文字だけを使用することを 要求しているため、言語タグの構成に文字集合上の問題はないはずである。 言語タグに基づくテキストのレンダリングについては、ここでは扱わない。 歴史的に、一部の処理では、特定の文字列をどのように レンダリングすべきかを推測するために、文字集合／エンコーディング 情報（またはその他の外部情報）の使用に依存してきた。 特に、日本語、中国語、韓国語で使用される漢字の言語および 文化固有の字形差に該当し、たとえば EUC-JP のような日本語の 文字エンコーディングを使用することにより、テキスト自体が 日本語であることが示唆される。言語タグがテキスト範囲に 適用されている場合、レンダリングエンジンはその情報を使用して フォントをより適切に選択したり、その他のレンダリング上の Phillips & Davis ベスト・カレント・プラクティス [72ページ]
RFC 5646 言語タグ 2009年9月 選択を行ったりできる場合がある。特に、異なる書記伝統を持つ 言語が同じ文字を使用する場合に有用である。 8. RFC 4646 からの変更点 この RFC 4646 改訂の主な目的は、ISO 639 の新しい二つの部分 （ISO 639-3 および ISO 639-5）と、それに伴う言語コードの集合を IANA Language Subtag Registry に組み込むことであった。 これにより、以前にサポートされていたものよりもはるかに多くの 言語および言語集合を識別できる。 これらの目的を達成するための、この文書における具体的な変更点は 次のとおりである。 o ISO 639-3 および ISO 639-5 コードを、主言語および拡張言語 サブタグとして使用するために組み込む方法を定義した。 また、追加の 'extlang' サブタグの使用を恒久的に予約し禁止した。 これを実現するために必要な変更は次のとおりである。 * ABNF コメントを変更した。 * ISO 639-1 および ISO 639-2 に加えて ISO 639-3 および ISO 639-5 を参照するよう、さまざまな登録および安定性要件の セクションを更新した。 * 拡張言語サブタグが使用されなくなった箇所から、その参照を 削除するよう本文を編集した。 * 拡張言語サブタグに関するセクションで変更を説明した。 o 旧来のタグに関連する ABNF を変更した。irregular タグを 列挙するようになった。整形式の旧来のタグは現在 'langtag' 生成規則によって記述され、その結果 'grandfathered' 生成規則は削除された。また、 両種類の旧来タグについての説明を セクション 2.2.8 に追加した。 o セクション 4.1 に「collections」に関する段落を追加した。 o セクション 3.1 の 'Tag' フィールドの大文字化規則を変更した。 o セクション 3.1 をサブセクションに分割した。 o 登録手続きを通じて 'Suppress-Script' フィールドを追加、 変更、または削除できるよう セクション 3.5 を変更した。 これは RFC 4646 の正誤表に基づくものである。 o 地域コード 'CS'（旧セルビア・モンテネグロ）を使用していた 例を、代わりに 'RS'（セルビア）を使用するよう変更した。 Phillips & Davis ベスト・カレント・プラクティス [73ページ]
RFC 5646 言語タグ 2009年9月 o 逆順になった重複を含む重複を防止するため、 レコードの 'Description' フィールドを作成および保守する規則を 変更した。 o RFC 4646 が作成された理由についての長い説明をこのセクションから 削除し、それに伴って XML Schema への参照も削除した。 o 言語タグでは大文字と小文字を区別しないという事実を より強調するよう、セクション 2.1 の本文を変更した。 o "fr-Latn-CA" は 'fr' と 'Latn' の 'Suppress-Script' に従って いないため、セクション 2.1 の例 "fr-Latn-CA" を "sr-Latn-RS" および "az-Arab-IR" に置き換えた。 o セクション 2.2.9 で、singleton の重複確認を整形式性については 任意とするよう要件を変更した（有効性の確認では必須）。 o セクション 2.2.9 の旧来タグの確認に関する本文を変更し、 その一覧が現在 ABNF に含まれていることを示した。 o セクション 3.2 の本文を変更および追加した。職務内容を最初に配置した。 Language Subtag Reviewer がリストのモデレーションを含む さまざまな重要でない業務を委任できることを明確にする注記を 追加した。最後に、任命手続きを明確にし、レビュアーの決定および 業務について異議申し立てできることを明確にする本文を追加した。 o ietf-languages@iana.org リストが IESG によって任命された者によって 運営されることを明確にする本文を セクション 3.5 に追加した。 o 'language' レコードの最初の Description が、ISO 639-3 における 対応する言語の Reference Name と一致することを明確にする本文を セクション 3.1.5 に追加した。 o 特定のタグに関連する適合性クラスを定義するよう セクション 2.2.9 を変更した（以前は 'well-formed' と 'valid' が 実装を指していた）。[RFC 4646] で提供された ABNF から 'extlang' が削除されたことに関する注記を追加し、 この旧定義による整形式性を許容した。RFC 3066 の 整形式性への参照も追加した。 o この文書の将来の版ではレジストリ形式に新しいフィールド型を 追加する可能性があることを示し、認識できないフィールドを 実装が無視することを推奨する本文を セクション 3.1.2 の末尾に 追加した。 Phillips & Davis ベスト・カレント・プラクティス [74ページ]
RFC 5646 言語タグ 2009年9月 o レコードに 'Suppress-Script' フィールドがないことの意味に ついての本文を セクション 3.1.9 に追加した。 o 綴り間違いおよび誤植の修正を許可する本文を セクション 3.1.5 に追加した。 o 'Prefix' フィールドの競合（循環する prefix 参照など）を 禁止する本文を セクション 3.1.8 に追加した。 o サブタグレビュアーに、2 週間の期間後に自身の決定 （または延長）を通知することを要求するよう、 セクション 3.5 の本文を変更した。また、あらゆる決定または 決定しなかったことに異議申し立てできることを明確にした。 o タグ選択に関する（それまで逸話的だった）基本原則を含め、 書記されないアプリケーションで文字体系サブタグを使用しない ことを明確にするよう、セクション 4.1 の本文を変更した。 o 同じ変種を一つのタグ内で複数回使用することを禁止した （すなわち "de-1901-1901"）。以前は単なる推奨 ("SHOULD") であった。 o セクション 4.4.1 の図から、不適切な [RFC2119] 用語を削除した。 o セクション 4.5 で "zh-guoyu" を非推奨とする例を "zh-hakka"->"hak" に置き換え、その変更がこの文書によって 行われたことを明記した。 o セクション 4.1 の "mul"/"und" を扱う部分を置き換え、 サブタグ 'zxx' および 'mis' とタグ "i-default" を含めた。 RFC 2277 への規範的参照も追加した。 o 登録要求へのあらゆる変更は IANA に提出する前に <ietf-languages@iana.org> リストに送信しなければならないことを 明確にする本文を セクション 3.5 に追加した。 o record-jar 形式の ABNF を、LWSP 生成規則を使用するものから、 [RFC5234] の obs-FWS に類似した折り返し空白生成規則を 使用するものに変更した。これにより、フィールド内に意図しない 空行が入ることを事実上防止する。 o Language Subtag Reviewer が完全な登録フォームを IANA に送り、 IANA がフォームからレコードを抽出し、さらにフォームを レジストリとは別に保存しなければならないことを明確にするため、 セクション 3.3、3.5、5.1 の本文を明確化および改訂した。 Phillips & Davis ベスト・カレント・プラクティス [75ページ]
RFC 5646 言語タグ 2009年9月 o レジストリが更新されるたびに IANA が ietf-languages-announcements リストに通知を送ることを要求する 本文を セクション 5 に追加した。 o レジストリの文字エンコーディングとして UTF-8 を使用するよう 変更した。これに伴い、登録手続きにおける IANA および Language Subtag Reviewer への追加の指示も含まれる。 o 'UK' 以外の「例外的に予約された」ISO 3166-1 コードを レジストリに含めるよう、セクション 2.2.4 の規則を変更した。 特に、これによりコード 'EU'（欧州連合）を言語タグの形成に 使用したり、より一般的にはレジストリを地域コードに使用する アプリケーションからこのサブタグを参照したりできる。 o 不要な規範的 [RFC2119] 用語を削除するよう、 IANA に関する考慮事項のセクション（セクション 5）を変更した。 9. 参考文献 9.1. 規範的参考文献 [ISO15924] International Organization for Standardization, "ISO 15924:2004. 情報およびドキュメンテーション -- 文字体系名を表すためのコード", 2004年1月。 [ISO3166-1] International Organization for Standardization, "ISO 3166-1:2006. 国およびその下位区分の名称を 表すためのコード -- 第1部: 国コード", 2006年11月。 [ISO639-1] International Organization for Standardization, "ISO 639-1:2002. 言語名を表すためのコード -- 第1部: Alpha-2 コード", 2002年7月。 [ISO639-2] International Organization for Standardization, "ISO 639-2:1998. 言語名を表すためのコード -- 第2部: Alpha-3 コード", 1998年10月。 [ISO639-3] International Organization for Standardization, "ISO 639-3:2007. 言語名を表すためのコード - 第3部: 言語を包括的に網羅するための Alpha-3 コード", 2007年2月。 Phillips & Davis ベスト・カレント・プラクティス [76ページ]
RFC 5646 言語タグ 2009年9月 [ISO639-5] International Organization for Standardization, "ISO 639-5:2008. 言語名を表すためのコード -- 第5部: 言語族および言語グループのための Alpha-3 コード", 2008年5月。 [ISO646] International Organization for Standardization, "ISO/IEC 646:1991, 情報技術 -- 情報交換用 ISO 7 ビット符号化文字集合。", 1991年。 [RFC2026] Bradner, S., "インターネット標準化プロセス -- 改訂 3", BCP 9, RFC 2026, 1996年10月。 [RFC2119] Bradner, S., "要求レベルを示すために RFC で使用する キーワード", BCP 14, RFC 2119, 1997年3月。 [RFC2277] Alvestrand, H., "文字集合と言語に関する IETF ポリシー", BCP 18, RFC 2277, 1998年1月。 [RFC3339] Klyne, G., Ed. and C. Newman, "インターネット上の 日付と時刻: タイムスタンプ", RFC 3339, 2002年7月。 [RFC4647] Phillips, A. and M. Davis, "言語タグの照合", BCP 47, RFC 4647, 2006年9月。 [RFC5226] Narten, T. and H. Alvestrand, "RFC における IANA に関する考慮事項のセクションを書くための指針", BCP 26, RFC 5226, 2008年5月。 [RFC5234] Crocker, D. and P. Overell, "構文仕様のための 拡張 BNF: ABNF", STD 68, RFC 5234, 2008年1月。 [SpecialCasing] The Unicode Consoritum, "Unicode Character Database, 特殊な大文字・小文字変換のプロパティ", 2008年3月, <http:// unicode.org/Public/UNIDATA/SpecialCasing.txt>. [UAX14] Freitag, A., "Unicode Standard Annex #14: 改行 プロパティ", 2006年8月, <http://www.unicode.org/reports/tr14/>. [UN_M.49] Statistics Division, United Nations, "統計用途の 標準国・地域コード", 改訂 4 (United Nations publication, Sales No. 98.XVII.9, 1999年6月。 Phillips & Davis ベスト・カレント・プラクティス [77ページ]
RFC 5646 言語タグ 2009年9月 [Unicode] Unicode Consortium, "The Unicode Consortium. The Unicode Standard, Version 5.0, (Boston, MA, Addison- Wesley, 2003. ISBN 0-321-49081-0)", 2007年1月。 9.2. 参考情報 [CLDR] "Common Locale Data Repository プロジェクト", <http://cldr.unicode.org>. [RFC1766] Alvestrand, H., "言語を識別するためのタグ", RFC 1766, 1995年3月。 [RFC2028] Hovey, R. and S. Bradner, "IETF 標準化プロセスに 関与する組織", BCP 11, RFC 2028, 1996年10月。 [RFC2046] Freed, N. and N. Borenstein, "多目的インターネット メール拡張 (MIME) 第2部: メディアタイプ", RFC 2046, 1996年11月。 [RFC2047] Moore, K., "MIME（多目的インターネットメール 拡張）第3部: 非 ASCII テキスト用 メッセージヘッダー拡張", RFC 2047, 1996年11月。 [RFC2231] Freed, N. and K. Moore, "MIME パラメーター値および 符号化語拡張: 文字集合、言語、および継続", RFC 2231, 1997年11月。 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, 1999年6月。 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16、ISO 10646 の 符号化方式", RFC 2781, 2000年2月。 [RFC3066] Alvestrand, H., "言語を識別するためのタグ", RFC 3066, 2001年1月。 [RFC3282] Alvestrand, H., "Content Language ヘッダー", RFC 3282, 2002年5月。 [RFC3552] Rescorla, E. and B. Korver, "セキュリティに関する 考慮事項について RFC テキストを書くための指針", BCP 72, RFC 3552, 2003年7月。 Phillips & Davis ベスト・カレント・プラクティス [78ページ]
RFC 5646 言語タグ 2009年9月 [RFC3629] Yergeau, F., "UTF-8、ISO 10646 の変換形式", STD 63, RFC 3629, 2003年11月。 [RFC4645] Ewell, D., "初期言語サブタグレジストリ", RFC 4645, 2006年9月。 [RFC4646] Phillips, A. and M. Davis, "言語を識別するためのタグ", BCP 47, RFC 4646, 2006年9月。 [RFC5645] Ewell, D., Ed., "言語サブタグレジストリの更新", 2009年9月。 [UTS35] Davis, M., "Unicode Technical Standard #35: Locale Data Markup Language (LDML)", 2007年12月, <http://www.unicode.org/reports/tr35/>. [iso639.prin] ISO 639 Joint Advisory Committee, "ISO 639 Joint Advisory Committee: ISO 639 保守の作業原則", 2000年3月, <http://www.loc.gov/ standards/iso639-2/iso639jac_n3r.html>. [record-jar] Raymond, E., "The Art of Unix Programming", 2003, <urn:isbn:0-13-142901-9>. Phillips & Davis ベスト・カレント・プラクティス [79ページ]
RFC 5646 言語タグ 2009年9月 付録 A. 言語タグの例（参考） 単純な言語サブタグ: de（ドイツ語） fr（フランス語） ja（日本語） i-enochian（旧来のタグの例） 言語サブタグ + 文字体系サブタグ: zh-Hant（繁体字で記述された中国語） zh-Hans（簡体字で記述された中国語） sr-Cyrl（キリル文字で記述されたセルビア語） sr-Latn（ラテン文字で記述されたセルビア語） 拡張言語サブタグと、それに対応する主言語サブタグ: zh-cmn-Hans-CN（中国語、官話、簡体字、中国で使用） cmn-Hans-CN（官話、簡体字、中国で使用） zh-yue-HK（中国語、広東語、香港特別行政区で使用） yue-HK（広東語、香港特別行政区で使用） 言語-文字体系-地域: zh-Hans-CN（中国本土で使用される、簡体字で記述された中国語） sr-Latn-RS（セルビアで使用される、ラテン文字で記述された セルビア語） Phillips & Davis ベスト・カレント・プラクティス [80ページ]
RFC 5646 言語タグ 2009年9月 言語-変種: sl-rozaj（スロベニア語のレシア方言） sl-rozaj-biske（スロベニア語のレシア方言の サン・ジョルジョ方言） sl-nedis（スロベニア語のナディジャ方言） 言語-地域-変種: de-CH-1901（スイスで使用される、1901 年の変種 [正書法] を使用したドイツ語） sl-IT-nedis（イタリアで使用されるスロベニア語、ナディジャ方言） 言語-文字体系-地域-変種: hy-Latn-IT-arevela（イタリアで使用される、ラテン文字で記述された 東アルメニア語） 言語-地域: de-DE（ドイツ向けのドイツ語） en-US（米国で使用される英語） es-419（国連地域コードを使用した、ラテンアメリカおよび カリブ地域に適したスペイン語） 私的利用サブタグ: de-CH-x-phonebk az-Arab-x-AZE-derbend 私的利用レジストリ値: x-whatever（singleton 'x' を使用した私的利用） qaa-Qaaa-QM-x-southern（すべて私的利用のタグ） de-Qaaa（ドイツ語、私的文字体系） sr-Latn-QM（セルビア語、ラテン文字、私的地域） sr-Qaaa-RS（セルビア語、私的文字体系、セルビア向け） Phillips & Davis ベスト・カレント・プラクティス [81ページ]
RFC 5646 言語タグ 2009年9月 拡張を使用するタグ（例のみ -- 拡張は、この文書の改訂または更新、 あるいは RFC によって定義されなければならない）: en-US-u-islamcal zh-CN-a-myext-x-private en-a-myext-b-another 無効なタグの例: de-419-DE（二つの地域タグ） a-DE（主位置で 1 文字のサブタグを使用。なお、"i-" で始まる 有効な旧来タグがいくつか存在する） ar-a-aaa-b-bbb-a-ccc（同じ 1 文字 prefix を持つ二つの拡張） 付録 B. 登録フォームの例 言語サブタグ登録フォーム 1. 要求者の氏名: Han Steenwijk 2. 要求者の電子メールアドレス: han.steenwijk @ unipd.it 3. 要求するレコード: Type: variant Subtag: biske Description: レシア語のサン・ジョルジョ方言 Description: レシア語のビラ方言 Prefix: sl-rozaj Comments: サン・ジョルジョ／ビラ方言は、レシア語の 四つの主要な地域方言の一つである 4. サブタグの意図する意味: サン・ジョルジョ／ビラで話されるレシア語の地域変種 5. 言語について公開された説明（書籍または 論文）への参照: -- Jan I.N. Baudouin de Courtenay - Opyt fonetiki rez'janskich govorov, Varsava - Peterburg: Vende - Kozancikov, 1875. Phillips & Davis ベスト・カレント・プラクティス [82ページ]
RFC 5646 言語タグ 2009年9月 言語サブタグ登録フォーム 1. 要求者の氏名: Jaska Zedlik 2. 要求者の電子メールアドレス: jz53 @ zedlik.com 3. 要求するレコード: Type: variant Subtag: tarask Description: タラシュケヴィツァ正書法によるベラルーシ語 Prefix: be Comments: このサブタグは Branislau Taraskievic のベラルーシ語 正書法を表し、Juras Buslakou, Vincuk Viacorka, Zmicier Sanko, and Zmicier Sauka による "Bielaruski klasycny pravapis" (Vilnia-Miensk 2005) で公開されたものである。 4. サブタグの意図する意味: このサブタグは、Juras Buslakou, Vincuk Viacorka, Zmicier Sanko, and Zmicier Sauka による "Bielaruski klasycny pravapis" (Vilnia-Miensk 2005) で公開されたベラルーシ語正書法を 表すことを意図している。 5. 言語について公開された説明（書籍または 論文）への参照: Taraskievic, Branislau. Bielaruskaja gramatyka dla skol. Vilnia: Vyd. "Bielaruskaha kamitetu", 1929, 5th edition. Buslakou, Juras; Viacorka, Vincuk; Sanko, Zmicier; Sauka, Zmicier. Bielaruski klasycny pravapis. Vilnia-Miensk, 2005. 6. その他の関連情報: タラシュケヴィツァ正書法によるベラルーシ語は、特にベラルーシ語を 使用するインターネット分野で広く使用されるようになったが、 それ以外にも、このベラルーシ語正書法を使用して印刷されている 書籍や新聞がある。 付録 C. 謝辞 貢献者の一覧は必然的に不完全なものとなる。以下は、 この文書を現在の形にするために貢献した人々の中からの 一部の選出にすぎないものとして受け取っていただきたい。 この文書の前身である RFC 4646、RFC 4647、RFC 3066、および RFC 1766 の 貢献者は、直接または間接的にこの文書に多大な貢献を行い、 言語タグの成功に大きく寄与した。 Phillips & Davis ベスト・カレント・プラクティス [83ページ]
RFC 5646 言語タグ 2009年9月 次の人々がこの文書に貢献した。 Stephane Bortzmeyer, Karen Broome, Peter Constable, John Cowan, Martin Duerst, Frank Ellerman, Doug Ewell, Deborah Garside, Marion Gunn, Alfred Hoenes, Kent Karlsson, Chris Newman, Randy Presuhn, Stephen Silver, Shawn Steele, and many, many others. RFC 1766 および 3066 を創始し、この人物なしにはこの文書が 実現しなかったであろう Harald Tveit Alvestrand に、 特別な感謝を捧げる。 RFC 1766/RFC 3066 のほぼ全期間にわたって Language Tag Reviewer を務め、さらに RFC 4646 の採用以降 Language Subtag Reviewer を務めた Michael Everson にも、 特別な感謝を捧げる。 最初の完全なサブタグレジストリを作成し、新規登録の支援と保守を 行い、さらに RFC 4645 と [RFC5645] の両方を注意深く編集した Doug Ewell にも 特別な感謝を捧げる。 著者の連絡先 Addison Phillips (editor) Lab126 EMail: addison@inter-locale.com URI: http://www.inter-locale.com Mark Davis (editor) Google EMail: markdavis@google.com Phillips & Davis ベスト・カレント・プラクティス [84ページ]