ネットワーク作業部会 A. Phillips, Ed. Request for Comments: 5646 Lab126 BCP: 47 M. Davis, Ed. Obsoletes: 4646 Google Category: Best Current Practice 2009年9月 言語を識別するためのタグ 概要 この文書は、情報オブジェクトで使用されている言語を示すことが 望ましい場合に使用する言語タグの構造、内容、構築方法、および 意味を記述する。また、言語タグで使用する値を登録する方法と、 私的な交換のための利用者定義拡張の作成についても記述する。 このメモの位置づけ この文書は、インターネットコミュニティのためのインターネット Best Current Practices を規定するものであり、改善のための議論と 提案を求める。このメモの配布に制限はない。 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] を置き換える（[RFC4646] は [RFC3066] を廃止し、 さらに [RFC3066] は [RFC1766] を置き換えていた）。この文書は [RFC4647] と組み合わせて BCP 47 を構成する。この文書における 変更点の一覧については、Section 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 言語タグの例については、Appendix A を参照されたい。 すべてのサブタグの最大長は 8 文字である。言語タグ内では空白は 許可されない。ABNF 生成規則 'variant' には微妙な点がある。 数字で始まる変種は最小長が 4 文字である一方、文字で始まる 変種は最小長が 5 文字である。 [RFC5234] はオクテットに言及しているが、この文書で説明する 言語タグは US-ASCII [ISO646] レパートリの文字列である。言語タグは、 関連する US-ASCII レパートリ部分を包含している限り、他の符号化 を使用する文書およびアプリケーションで使用してよい（MAY）。 その例として、[Unicode] の UTF-16LE [RFC2781] 符号化を使用する XML 文書が挙げられる。 2.1.1. 言語タグの書式化 言語タグおよびそのサブタグは、私用および拡張を含め、常に大文字 小文字を区別しないものとして扱われる。いくつかのサブタグには 大文字化の慣習が存在するが、これらは意味を担うものと見なしては ならない（MUST NOT）。 したがって、タグ "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" と同等と見な される。 言語タグでは大文字小文字の違いは意味を持たないが、一貫した 言語タグの書式化および提示は利用者の助けとなる。登録簿に おけるサブタグの形式は、言語タグで使用する形式として RECOMMENDED である。この形式は一般に、サブタグの由来となる 各種 ISO 標準の一般的な慣習に対応する。 これらの慣習には次が含まれる。 o [ISO639-1] は、言語コードを小文字で記述することを推奨する （'mn' モンゴル語）。 o [ISO15924] は、用字コードを小文字で、先頭文字だけを大文字に することを推奨する（'Cyrl' キリル文字）。 o [ISO3166-1] は、国コードを大文字にすることを推奨する（'MN' モンゴル）。 実装は、登録簿にアクセスせずに次のようにこの形式を再現できる。 拡張および私用サブタグを含むすべてのサブタグは、小文字を使用 する。ただし二つの例外がある。タグの先頭に現れず、かつ singleton の後にも現れない 2 文字および 4 文字のサブタグである。 そのような 2 文字サブタグはすべて大文字（タグ "en-CA-x-ca" や "sgn-BE-FR" のように）であり、4 文字サブタグは titlecase （タグ "az-Latn-x-latn" のように）である。 注記: 特定のロケールにおける ASCII 文字のケースフォールディング は、慎重に扱わないと、非 ASCII 文字値を生成することがある。 Unicode Character Database ファイル "SpecialCasing.txt" [SpecialCasing] は、これにより問題を引き起こすことが知られて いる具体的な事例を定義している。特に、トルコ語および アゼルバイジャン語では文字 'i'（U+0069）が U+0130（LATIN CAPITAL LETTER I WITH DOT ABOVE）へ大文字化される。実装者は、 サブタグのケースフォールディングがこの値を生成しないよう、 ロケール中立な大文字小文字処理を指定すべきである（SHOULD）。 この値は言語タグでは不正である。たとえば、地域サブタグ 'in' をトルコ語ロケール規則で大文字化すると、期待される 'IN' では なく、列 U+0130 U+004E が生成される。 Phillips & Davis 最善現行慣行 [ページ 7]
RFC 5646 言語タグ 2009年9月 2.2. 言語サブタグの出典と解釈 言語タグおよびそのサブタグの名前空間は、この文書の Section 5 の 規則に従って Internet Assigned Numbers Authority（IANA）により 管理される。IANA が維持する Language Subtag Registry は、有効な サブタグの出典である。この節で参照される他の標準は、その登録簿 のための出典資料を提供する。 この文書で使用する用語: o "Tag" は、"sr-Latn-RS" や "az-Arab-IR" など、完全な言語 タグを指す。この文書におけるタグの例は二重引用符で囲む （"en-US"）。 o "Subtag" は、ハイフンで区切られたタグの特定部分を指す。 たとえば、タグ "zh-Hant-CN" におけるサブタグ 'zh', 'Hant', 'CN' である。この文書におけるサブタグの例は単一 引用符で囲む（'Hant'）。 o "Code" は、外部標準で定義される値（およびこの文書で サブタグとして使用される値）を指す。たとえば 'Hant' は、 言語タグで使用する 'Hant' 用字サブタグを定義するために 使用された [ISO15924] 用字コードである。この文書におけるコードの例は 単一引用符で囲む（'en', 'Hant'）。 言語タグは、各サブタグ型が一意の長さおよび内容上の制限を持つ よう設計されている。これにより、サブタグ自体の内容が認識され ない場合でも、サブタグの型を識別できる。これにより、基礎となる 標準または IANA 登録簿の最新バージョンを参照せずにタグを構文 解析および処理でき、タグ構文解析時の関連する例外処理も簡単に なる。 IANA 登録簿中の一部のサブタグは、基礎となる標準に由来しない。 これらはタグ中の特定位置にのみ現れることができる。すなわち、 主言語サブタグまたは変種サブタグとしてのみ出現できる。 私用および拡張サブタグの列は、サブタグ列の末尾に現れなければ ならず（MUST）、この文書で定義される他のサブタグと混在しては ならない（MUST NOT）。これらの列は、次のように予約されている 単一文字サブタグによって導入される。 o 単一文字サブタグ 'x' は、私用サブタグの列を導入する。任意の 私用サブタグの解釈は、私的な合意のみによって定義され、この 節の規則、またはこの文書で定義される任意の標準または登録簿 によって定義されない。 Phillips & Davis 最善現行慣行 [ページ 8]
RFC 5646 言語タグ 2009年9月 o 単一文字サブタグ 'i' は、"i-default" など一部の祖父化タグで 使用される。この場合、常に先頭位置に現れ、拡張と混同される ことはない。 o その他すべての単一文字および単一数字のサブタグは、 Section 3.7 で説明する標準化された拡張サブタグ列を導入する ために予約されている。 2.2.1. 主言語サブタグ 主言語サブタグは言語タグ中の最初のサブタグであり、二つの例外を 除いて省略できない。 o 主サブタグとしての単一文字サブタグ 'x' は、その言語タグが 意味を私的な合意によってのみ定義されるサブタグだけから 構成されることを示す。たとえばタグ "x-fr-CH" では、私的な 合意が存在しない限り、サブタグ 'fr' および 'CH' はフランス語 またはスイスの国（または IANA 登録簿中の他の値）を表さない。 Section 4.6 を参照されたい。 o 単一文字サブタグ 'i' は、"i-klingon" や "i-bnn" など一部の 祖父化タグ（Section 2.2.8 参照）で使用される。（他の祖父化 タグは、その先頭位置に主言語サブタグを持つ。） 主言語サブタグには次の規則が適用される。 1. 2 文字の主言語サブタグは、標準 "ISO 639-1:2002, Codes for the representation of names of languages -- Part 1: Alpha-2 code" [ISO639-1] に見られる割当、または ISO 639-1 登録機関 （RA）もしくは管理標準化団体が後に行った割当に従って、 IANA 登録簿で定義された。 2. IANA 登録簿中の 3 文字の主言語サブタグは、次の追加的な ISO 639 部のいずれかに見られる割当、または関連する ISO 639 登録機関もしくは管理標準化団体が後に行った割当に従って 定義された。 A. "ISO 639-2:1998 - Codes for the representation of names of languages -- Part 2: Alpha-3 code - edition 1" [ISO639-2] Phillips & Davis 最善現行慣行 [ページ 9]
RFC 5646 言語タグ 2009年9月 B. "ISO 639-3:2007 - Codes for the representation of names of languages -- Part 3: Alpha-3 code for comprehensive coverage of languages" [ISO639-3] C. "ISO 639-5:2008 - Codes for the representation of names of languages -- Part 5: Alpha-3 code for language families and groups" [ISO639-5] 3. 範囲 'qaa' から 'qtz' までのサブタグは、言語タグにおける 私用のために予約されている。これらのサブタグは、ISO 639-2 により私用として予約されたコードに対応する。これらのコード は、（'x-' に続く私用サブタグを使用する代わりに）未登録の 主言語サブタグとして使用してよい（MAY）。私用サブタグの詳細 については Section 4.6 を参照されたい。 4. 4 文字の言語サブタグは、将来の標準化の可能性のために予約 されている。 5. IANA 登録簿中の長さ 5 から 8 文字の任意の言語サブタグは、 Section 3.5 の登録手続きによって定義され、主言語サブタグを 形成するために使用してよい（MAY）。このような登録に含まれ うる例として、祖父化された IANA 登録 "i-enochian" がある。 サブタグ 'enochian' は、（ISO 639 がこの言語を先に登録しない と仮定すれば）IANA 登録簿に主言語サブタグとして登録される 可能性があり、"enochian-AQ" や "enochian-Latn" などのタグを 有効にする。 この文書が作成された時点では、この種のサブタグの例は存在 しなかった。この型の将来の登録は推奨されない。新たに提案 される主言語を登録しようとする場合は、ISO 639 登録機関へ 申請しなければならない（MUST）。ISO 639 登録機関によって 却下された提案は、主言語サブタグの基準を満たす可能性が低く、 したがって登録される可能性も低い。 6. その他の値は、この文書の改訂または更新による場合を除き、 主サブタグに割り当ててはならない（MUST NOT）。 言語が ISO 639-1 の 2 文字コードと、ISO 639-2、ISO 639-3、 または ISO 639-5 によって割り当てられた 3 文字コードの両方を 持つ場合、IANA 登録簿では ISO 639-1 の 2 文字コードのみが定義 される。 言語が ISO 639-1 の 2 文字コードを持たず、その言語の ISO 639-2/T（Terminology）コードと ISO 639-2/B（Bibliographic） コードが異なる場合、Terminology コードのみが IANA 登録簿で定義 される。この文書が作成された時点では、両種の 3 文字コードを 持つすべての言語には 2 文字コードも割り当てられていた。 Phillips & Davis 最善現行慣行 [ページ 10]
RFC 5646 言語タグ 2009年9月 今後、この性質の割当が生じることはないと期待される。 タグの正準形式に不安定性が生じることを避けるため、ISO 639-2 または ISO 639-3 のいずれかに 3 文字コードがすでに含まれている 言語について、ISO 639-1 に 2 文字コードが追加された場合、その 2 文字コードは登録してはならない（MUST NOT）。Section 3.4 を 参照されたい。 たとえば、ある内容に 'haw'（ハワイ語）というタグが付けられて いて、現在その言語に 2 文字コードがない場合、後日 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' フィールドで示される）と常に一緒に 使用される。登録簿に拡張言語サブタグを持つすべての言語は、 登録簿に同一の主言語サブタグレコードも持つ。この主言語サブタグ は、言語タグを形成するために RECOMMENDED である。拡張言語 サブタグには次の規則が適用される。 1. 拡張言語サブタグは、3 文字サブタグだけから構成される。 登録簿で定義されているすべての拡張言語サブタグレコードは、 [ISO639-3] に見られる割当に従って定義された。[ISO639-5] で 定義されるような言語の集合およびグループは、拡張言語 サブタグから明示的に除外される。 Phillips & Davis 最善現行慣行 [ページ 11]
RFC 5646 言語タグ 2009年9月 2. 拡張言語サブタグレコードは、その拡張言語サブタグに適切な サブタグまたはサブタグ列を示す 'Prefix' フィールドを正確に 一つ含まなければならない（MUST）。 3. 拡張言語サブタグレコードは 'Preferred-Value' を含まなければ ならない（MUST）。'Preferred-Value' フィールドと 'Subtag' フィールドは同一でなければならない（MUST）。 4. ABNF 生成規則 'extlang' は言語タグ中で最大三つの拡張言語 タグを許可しているが、拡張言語サブタグはその 'Prefix' に別の 拡張言語サブタグを含んではならない（MUST NOT）。すなわち、 言語タグ中の第二および第三の拡張言語サブタグ位置は恒久的に 予約されており、その位置にこれらのサブタグを含むタグは、 現在も将来も常に無効である。 たとえば、マクロ言語である中国語（'zh'）は複数の言語を包含する。 互換性上の理由から、これら各言語は登録簿に主言語サブタグと 拡張言語サブタグの両方を持つ。これらのうち選定例として、贛語 （'gan'）、広東語（'yue'）、官話（'cmn'）がある。それぞれは マクロ言語 'zh'（中国語）に包含される。したがって、それぞれは 登録簿レコードに接頭辞 "zh" を持つ。これにより、贛語は "zh-gan" または "gan" で始まるタグで表され、広東語は "yue" または "zh-yue" のいずれかで始まるタグで表され、官話は "zh-cmn" または "cmn" で表される。言語サブタグ 'zh' は、拡張 言語サブタグなしで、あるリソースを中国語の特定されない変種と してラベル付けするために引き続き使用できる一方、主言語サブタグ （'gan', 'yue', 'cmn'）は拡張言語形式（"zh-gan", "zh-yue", "zh-cmn"）を使用するよりも優先される。 2.2.3. 用字サブタグ 用字サブタグは、言語またはその方言の書き言葉の形を区別する 用字または書記体系の変異を示すために使用される。用字サブタグ には次の規則が適用される。 1. 用字サブタグは、任意の主言語および拡張言語サブタグの後に 続き、他のいかなる型のサブタグよりも前に置かなければなら ない（MUST）。 2. 用字サブタグは 4 文字から構成され、[ISO15924]（"Information and documentation -- Codes for the representation of names of scripts"）に見られる割当に従って、または ISO 15924 登録機関 もしくは管理標準化団体により後に割り当てられたものとして 定義された。ISO 15924 によって割り当てられたコードのみが 登録の対象として考慮される。 Phillips & Davis 最善現行慣行 [ページ 12]
RFC 5646 言語タグ 2009年9月 3. 用字サブタグ 'Qaaa' から 'Qabx' までは、言語タグにおける 私用のために予約されている。これらのサブタグは、ISO 15924 によって私用として予約されたコードに対応する。これらの コードは、未登録の用字値として使用してよい（MAY）。私用 サブタグの詳細については Section 4.6 を参照されたい。 4. 言語タグ中には最大一つの用字サブタグしか存在してはならず （MUST）、その用字サブタグがタグに識別上の価値を追加しない 場合、または主言語もしくは拡張言語サブタグのサブタグ登録簿 レコードに該当する用字サブタグを列挙する 'Suppress-Script' フィールドが含まれる場合、その用字サブタグは省略すべきで ある（SHOULD）。 例: "sr-Latn" は、ラテン文字を用いて書かれたセルビア語を表す。 2.2.4. 地域サブタグ 地域サブタグは、特定の国、領土、または地域に関連する、または 適した言語的変異を示すために使用される。通常、地域サブタグは 地域方言や用法、地域固有の綴り慣習などの変異を示すために使用 される。また、たとえばラテンアメリカ全域で有用となるように 調整されたスペイン語の内容のように、ある地域全体で使用するのに 適切な形で内容が表現されていることを示すためにも使用できる。 地域サブタグには次の規則が適用される。 1. 地域サブタグは、任意の主言語、拡張言語、または用字サブタグ の後に続き、他のいかなる型のサブタグよりも前に置かなければ ならない（MUST）。 2. 2 文字の地域サブタグは、[ISO3166-1]（"Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes"）に見られる割当に従い、alpha-2 国コード の一覧を使用して、または ISO 3166-1 保守機関もしくは管理標準化 団体により後に行われた割当を使用して定義された。さらに、 ISO 3166-1 において「例外的に予約された」（"assigned" では ない）コードも登録簿で定義された。ただし 'UK' は、割当済み コード 'GB' の完全な同義語であるため例外である。 3. 地域サブタグ 'AA', 'QM'-'QZ', 'XA'-'XZ', および 'ZZ' は、 言語タグにおける私用のために予約されている。これらのサブ タグは、ISO 3166 により私用として予約されたコードに対応する。 これらのコードは、（私用サブタグ列を使用する代わりに）私用 地域サブタグとして使用してよい（MAY）。私用サブタグの詳細 については Section 4.6 を参照されたい。 Phillips & Davis 最善現行慣行 [ページ 13]
RFC 5646 言語タグ 2009年9月 4. 3 文字の地域サブタグは数字（number）文字のみから構成され、 UN Standard Country or Area Codes for Statistical Use [UN_M.49] に見られる割当、または管理標準化団体により後に行われた割当 に従って定義された。すべての UN M.49 コードが IANA 登録簿で 定義されるわけではない。次の規則は、有効なサブタグとして どのコードが登録簿に入力されるかを定義する。 A. 「大陸的なマクロ地理」または小地域に割り当てられた UN 数値コードは、登録簿に登録されなければならない （MUST）。これらのコードは、割り当てられた ISO 3166-1 alpha-2 コードに関連付けられず、通常は一つを超える国家、 州、省、または領土を含む超国家的な地域を表す。 B. 「経済的グループ」または「その他のグループ」の UN 数値 コードは、IANA 登録簿に登録してはならず（MUST NOT）、 言語タグを形成するために使用してはならない（MUST NOT）。 C. ISO 3166-1 が、以前ある国または地域に使用されていた コードを別の国または地域へ再割当し、そのコードがすでに 登録簿に存在する場合、その国または地域の UN 数値コード は Section 3.4 で説明するように登録簿に登録されなければ ならず（MUST）、そのコードが定義される国または地域を 表す言語タグを形成するために使用しなければならない （MUST）（再利用された ISO 3166-1 コードではなく）。 D. 登録簿に関連する ISO 3166-1 alpha-2 コードがある国または 地域の UN 数値コードは、登録簿に入力してはならず （MUST NOT）、言語タグを形成するために使用してはならない （MUST NOT）。登録簿中の ISO 3166 に基づくサブタグは、 問題の UN M.49 コードと実際に関連付けられていなければ ならないことに注意されたい。 E. 歴史的理由により、この文書が採用された時点で登録されて おらず、その時点では対応する ISO 3166-1 コードを持た なかった UN 数値コード 830（チャネル諸島）は、同じ意味を 持つ ISO 3166-1 コードが以前に登録されていないことを条件 として、Section 3.5 で説明する手続きにより IANA 登録簿に 入力してよい（MAY）。 F. 関連する ISO 3166-1 alpha-2 コードを持たない国または 地域に関するその他すべての UN 数値コードは、登録簿に 入力してはならず（MUST NOT）、言語タグを形成するために 使用してはならない（MUST NOT）。これらのコードに関する 詳細については Section 3.4 を参照されたい。 Phillips & Davis 最善現行慣行 [ページ 14]
RFC 5646 言語タグ 2009年9月 5. UN 文書の Appendix X にある英数字コードは、登録簿に入力 してはならず（MUST NOT）、言語タグを形成するために使用しては ならない（MUST NOT）。（この文書が作成された時点で、これらの 値は ISO 3166-1 alpha-2 コードに一致していた。） 6. 言語タグ中には最大一つの地域サブタグしか存在してはならず （MUST）、地域サブタグは、それがタグに識別上の価値を追加 しない場合などには省略してよい（MAY）。 例: "de-AT" は、オーストリア（'AT'）で使用されるドイツ語（'de'） を表す。 "sr-Latn-RS" は、セルビア（'RS'）で使用され、ラテン文字 （'Latn'）で書かれたセルビア語（'sr'）を表す。 "es-419" は、UN が定義するラテンアメリカおよびカリブ地域 （'419'）に適したスペイン語（'es'）を表す。 2.2.5. 変種サブタグ 変種サブタグは、他の利用可能なサブタグでは扱われない、言語また はその方言を定義する追加的でよく認識された変異を示すために使用 される。変種サブタグには次の規則が適用される。 1. 変種サブタグは、任意の主言語、拡張言語、用字、または地域 サブタグの後に続き、任意の拡張または私用サブタグ列よりも 前に置かなければならない（MUST）。 2. 変種サブタグは集合として、特定の外部標準に関連付けられて いない。登録簿中の変種サブタグの意味は、Section 3.5 で 定義される登録手続きの過程で定義される。特定の変種サブタグ が何らかの外部標準に関連付けられることはあり得ることに注意 されたい。しかし、登録に標準との関連付けは要求されない。 3. 複数の変種を使用して言語タグを形成してよい（MAY）。 4. 変種サブタグは、言語タグを形成するために使用される前に、 この文書の Section 3.5 の規則に従って IANA に登録されなけれ ばならない（MUST）。変種を他の型のサブタグと区別するため、 登録は次の長さおよび内容上の制限を満たさなければならない （MUST）。 1. 文字（a-z, A-Z）で始まる変種サブタグは、少なくとも 5 文字長でなければならない（MUST）。 Phillips & Davis 最善現行慣行 [ページ 15]
RFC 5646 言語タグ 2009年9月 2. 数字（0-9）で始まる変種サブタグは、少なくとも 4 文字長 でなければならない（MUST）。 5. 同一の変種サブタグは、言語タグ内で複数回使用してはならない （MUST NOT）。 * たとえば、タグ "de-DE-1901-1901" は有効ではない。 Language Subtag Registry 中の変種サブタグレコードは、一つ以上の 'Prefix'（Section 3.1.8）フィールドを含んでよい（MAY）。各 'Prefix' は、変種を使用するときに（必要に応じて他のサブタグと ともに）言語タグを形成するのに適したサブタグ列を示す。 接頭辞を共有するほとんどの変種は相互排他的である。たとえば、 ドイツ語正書法の変異 '1996' と '1901' は、異なる綴り改革の 年を表すため、同じタグで使用すべきではない（SHOULD NOT）。 ある変種が別の変種と組み合わせて意味を持って使用できる場合、 その変種は、その別の変種を列挙する 'Prefix' フィールドを登録簿 レコードに含めるべきである（SHOULD）。たとえば、'1996' とともに 使用することが意味を持つ別のドイツ語変種 'example' が作成された 場合、'example' は二つの 'Prefix' フィールド、すなわち "de" と "de-1996" を含めるべきである。 例: "sl-nedis" は、スロベニア語の Natisone または Nadiza 方言を 表す。 "de-CH-1996" は、スイスで使用され、紀元 1996 年に始まる 綴り改革に基づいて書かれたドイツ語を表す。 2.2.6. 拡張サブタグ 拡張は、各種アプリケーションで使用するために言語タグを拡張する 機構を提供する。拡張は、言語または言語タグに関連して一般的に 使用されるが、言語識別の一部ではない情報を識別することを目的 とする。Section 3.7 を参照されたい。拡張には次の規則が適用 される。 1. 拡張は少なくとも主言語サブタグの後に続かなければならない （MUST）。すなわち、言語タグは拡張で始まることはできない。 拡張は言語タグを拡張するものであり、上書きまたは置換する ものではない。たとえば "a-value" は well-formed な言語タグ ではないが、"de-a-value" は well-formed である。拡張は、 完全に私用であるタグ（すなわち "x-" で始まるタグ）では 使用できないことに注意されたい。 Phillips & Davis 最善現行慣行 [ページ 16]
RFC 5646 言語タグ 2009年9月 2. 拡張サブタグは、この文書で定義される他のサブタグから、 単一文字サブタグ（"singleton" と呼ばれる）によって区切ら れる。singleton は、Section 3.7 で説明する機構を介して登録 機関に割り当てられたものでなければならず（MUST）、私用 サブタグ列のために予約されている文字 'x' であってはならない （MUST NOT）。 3. 各 singleton サブタグは、各タグ中に最大一回しか現れては ならない（MUST）（私用サブタグとしての場合を除く）。すなわち、 singleton サブタグは繰り返してはならない（MUST NOT）。たとえば タグ "en-a-bbb-a-ccc" は、サブタグ 'a' が二度現れるため無効 である。タグ "en-a-bbb-x-a-ccc" は、singleton 'a' の二度目の 出現が私用列の中にあるため有効であることに注意されたい。 4. 拡張サブタグは、その singleton 接頭辞を定義する文書によって 設定される任意の要件、および保守機関によって提供される任意 の要件を満たさなければならない（MUST）。これらのサブタグの 登録簿が存在しない場合があり、検証処理器は拡張を検証する ことを要求されないことに注意されたい。 5. 各拡張サブタグは長さ 2 から 8 文字でなければならず（MUST）、 文字または数字のみから構成され、各サブタグは単一の '-' で 区切られる。拡張では（任意の言語サブタグと同様に）大文字 小文字の違いは無視され、この型の正規化されたサブタグは 小文字であることが期待される。 6. 各 singleton は、少なくとも一つの拡張サブタグに続かれなけれ ばならない（MUST）。たとえばタグ "tlh-a-b-foo" は、最初の singleton 'a' が直ちに別の singleton 'b' に続かれるため無効 である。 7. 拡張サブタグは、タグ中のすべての主言語、拡張言語、用字、 地域、および変種サブタグの後に続き、任意の私用サブタグ列 よりも前に置かなければならない（MUST）。 8. singleton の後、別の singleton の前にあるすべてのサブタグは その拡張の一部である。例: タグ "fr-a-Latn" において、 サブタグ 'Latn' は IANA Language Subtag Registry で定義される 用字サブタグ 'Latn' を表さない。その意味は拡張 'a' によって 定義される。 9. 一つのタグに複数の拡張が現れる場合、そのタグは Section 4.5 で説明するように、各拡張列を大文字小文字を区別しない ASCII 順に並べることによって正準化すべきである（SHOULD）。 たとえば、singleton 'r' のために拡張が定義され、それが示される サブタグを定義している場合、次のタグは有効な例となる。 "en-Latn-GB-boont-r-extended-sequence-x-private"。 Phillips & Davis 最善現行慣行 [ページ 17]
RFC 5646 言語タグ 2009年9月 2.2.7. 私用サブタグ 私用サブタグは、特定の文脈において私的な合意により重要となる 言語上の区別を示すために使用される。私用サブタグには次の規則が 適用される。 1. 私用サブタグは、この文書で定義される他のサブタグから、 予約済み単一文字サブタグ 'x' によって区切られる。 2. 私用サブタグは、すべてのサブタグに関する ABNF で定義される 形式および内容上の制約に適合しなければならない（MUST）。 すなわち、文字および数字のみから構成され、長さが 8 文字を 超えてはならない（MUST）。 3. 私用サブタグは、タグ中のすべての主言語、拡張言語、用字、 地域、変種、および拡張サブタグの後に続かなければならない （MUST）。別の言い方をすれば、singleton 'x' に続くすべての サブタグは私用と見なされなければならない（MUST）。例: タグ "en-x-US" 中のサブタグ 'US' は私用サブタグである。 4. タグは完全に私用サブタグだけから構成されてよい（MAY）。 5. 私用サブタグについて定義された出典は存在しない。私用サブ タグの使用は私的な合意のみによる。 6. 代替手段が存在する場合、または一般的な交換では、私用サブ タグは NOT RECOMMENDED である。私用サブタグの選択に関する 詳細については Section 4.6 を参照されたい。 たとえば、ある学者のグループが中世ギリシャ語のいくつかの文献 を研究しているとする。彼らは、文献中の異なる文体を識別する ため、何らかの私用サブタグの集合を使用することに合意するかも しれない。たとえば、"共通" 文体の文書には 'el-x-koine' を使用し、 アッティカ風の文体を模倣する他の文書には 'el-x-attic' を使用 するかもしれない。これらのサブタグは外部の処理またはシステム には認識されないが、そのグループの者が研究のために各種文献を 分類するのに有用である可能性がある。 登録簿には、ISO 639、ISO 15924、または ISO 3166 により私用の ために予約されたコードから派生したサブタグも存在する。これらを サブタグ 'x' に続く私用サブタグ列と混同してはならない。 Section 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' 型のレコード として維持されている。 以前に登録された残りのタグは "grandfathered" である。これらの タグは二つのグループ、'regular' と 'irregular' に分類される。 図 1 の 'langtag' 生成規則に（見かけ上）一致する祖父化タグは、 'regular' 祖父化タグと見なされる。これらのタグは、登録簿に個別 には現れない、または現れても異なる意味を持つ、一つ以上のサブ タグを含む。各タグは、その全体として、一つの言語または言語の 集合を表す。 ABNF の 'langtag' 生成規則に一致せず、それ以外では無効となる 祖父化タグは、'irregular' 祖父化タグと見なされる。"en-GB-oed" は "en-GB" の変種であるという例外を除き、それぞれは、その全体 として一つの言語を表す。 祖父化タグの多くは、その後の新しいサブタグの追加によって置き 換えられている。各置換済みレコードは、その値を表す言語タグを 形成するために使用すべき 'Preferred-Value' フィールドを含む。 たとえば、タグ "art-lojban" は主言語サブタグ 'jbo' によって 置き換えられる。 2.2.9. 適合性のクラス 実装は、この文書で説明される規則および慣行に関する能力を記述 する必要があることがある。タグはさまざまな方法で検査または 検証できるが、ここでは特に二つのタグ適合性クラスを正式に定義 する。 タグは、ABNF（Section 2.1）に適合する場合、"well-formed" と 見なされる。言語タグは、構文上 well-formed であっても、内容上 有効でないことがある。しかし、言語タグを伴う多くの操作は、 サブタグの意味または有効性について何も知らなくても十分に機能 する。 タグは、次の条件を満たす場合、"valid" と見なされる。 o タグが well-formed である。 Phillips & Davis 最善現行慣行 [ページ 19]
RFC 5646 言語タグ 2009年9月 o タグが祖父化タグの一覧に含まれるか、またはそのすべての主言語、 拡張言語、用字、地域、および変種サブタグが、特定の登録簿日付 の時点で IANA Language Subtag Registry に現れる。 o 重複する変種サブタグが存在しない。 o 重複する singleton（拡張）サブタグが存在しない。 タグの有効性は、そのタグを検証するために使用される登録簿の日付 に依存することに注意されたい。より新しい登録簿のコピーには、 古い版には存在しないサブタグが含まれることがある。 タグは、ある拡張（Section 3.7）について（特定のバージョン、 改訂、および日付の時点で）、上記の "valid" の基準を満たし、 さらに次の条件を満たす場合、その拡張について有効と見なされる。 タグの拡張部分で使用される各サブタグが、その拡張に従って 有効である。 古い仕様または言語タグ実装は、[RFC3066] を参照していることが ある。その文書の下では、より広い範囲のタグが well-formed と 見なされた。RFC 3066 の下で使用するうえで有効であった任意の タグは、この文書の構文の下でも well-formed かつ valid である。 以前の定義では well-formed であったが現在はそうでないものは、 無効または不正なタグだけである。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' など）以外で、 登録簿に現れないサブタグを使用する言語タグを割り当ててはなら ない（MUST NOT）。有効でないことに加え、利用者は将来の割当または 登録と衝突する危険も負う。 重要な注記: この文書に現れる 'Language-Tag' 生成規則は [RFC4646] のものと機能的には同等であるが、古い 'grandfathered' 生成規則から生じる well-formedness に関する特定の誤りを防ぐため 変更されている。 Phillips & Davis 最善現行慣行 [ページ 20]
RFC 5646 言語タグ 2009年9月 3. 登録簿の形式と保守 IANA Language Subtag Registry（「登録簿」）は、言語タグで有効な すべてのサブタグの包括的な一覧を含む。これにより、実装者は 言語タグを検証するための単純で信頼できる方法を得る。登録簿は、 拡張サブタグを除き、この文書またはその改訂版もしくは後継文書 の規定の下で言語タグに現れるすべてのサブタグを検証できるよう 保守される。さらに、各種サブタグの意味は長期にわたって明確で 安定したものとなる。（もちろん、私用サブタグの意味は登録簿に よって定義されない。） この節は、登録簿を、それに関連する保守および更新手続きとともに 定義し、また言語タグへの拡張のための登録簿（Section 3.7）も 定義する。 3.1. IANA 言語サブタグ登録簿の形式 IANA Language Subtag Registry は、この節で説明する形式の機械可読 ファイルであり、さらに Section 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 Normalization Form C（NFC）でなければならない（MUST）。 Phillips & Davis 最善現行慣行 [ページ 21]
RFC 5646 言語タグ 2009年9月 フィールドの集合が "record" を形成する。レコードは、列 "%%" （U+0025 U+0025）だけを含む行によって区切られる。 フィールドは論理的には単一のテキスト行であるが、ファイル形式に おける各テキスト行は長さ 72 バイトに制限される。これに対応する ため、field-body は複数行表現に分割できる。これを "folding" と 呼ぶ。folding は、行折り返しに関する慣用的な慣習に従って行われ る。これは通常、空白境界で行われるが、言語が単語間に空白を 使用しない場合など、値に空白が含まれないときは他の文字の間で 発生してもよい。いずれの場合でも、マルチバイト UTF-8 列の内部 や結合文字列の途中で改行してはならない（MUST NOT）。詳細につい ては [UAX14] を参照されたい。 ファイル形式は Unicode 文字集合を使用し、ファイル自体も UTF-8 符号化を使用して符号化されるが、特定フィールドの説明 （Section 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 は日付（Section 5.1 参照）を含み、登録簿の異なる バージョンを容易に認識できるようにする。 File-Date: 2004-06-28 %% 図 4: File-Date レコードの例 後続のレコードは複数のフィールドを含み、サブタグまたはタグの いずれかについての情報を表す。どちらの型のレコードも同一の構造 を持つが、"Subtag" レコードは field-name が "Subtag" の フィールドを含む一方、当然ながら "Tag" レコードは field-name が "Tag" のフィールドを含む点が異なる。field-name はレコードごとに 複数回現れてはならない（MUST NOT）。ただし 'Description', 'Comments', および 'Prefix' フィールドは例外である。 各レコードは、次の各フィールドの少なくとも一つずつを含まなけれ ばならない（MUST）。 o 'Type' * Type の field-body は、次の文字列のいずれかでなければ ならない（MUST）。"language", "extlang", "script", "region", "variant", "grandfathered", および "redundant"。これはタグ またはサブタグの型を示す。 o 'Subtag' または 'Tag' のいずれか * Subtag の field-body は、定義されるサブタグを含む。この フィールドは、'Type' が "language", "extlang", "script", "region", または "variant" のいずれかの値を持つすべての レコードに現れなければならない（MUST）。 * Tag の field-body は、完全な言語タグを含む。このフィールド は、'Type' が "grandfathered" または "redundant" のいずれか の値を持つすべてのレコードに現れなければならない（MUST）。 'Type' が "grandfathered" である場合、'Tag' field-body は Section 2.1 にある 'regular' または 'irregular' 生成規則の いずれかに列挙されたタグの一つとなる。 Phillips & Davis 最善現行慣行 [ページ 23]
RFC 5646 言語タグ 2009年9月 o 'Description' * Description の field-body は、サブタグまたはタグの非規範的な 説明を含む。 o 'Added' * Added の field-body は、そのレコードが登録された日付を含む。 祖父化タグまたは冗長タグの場合は、[RFC1766] または [RFC3066] の規則に基づいて対応するタグが登録された日付を含む。 各レコードは、次のフィールドも含んでよい（MAY）。 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' は、言語タグを形成 するときに好まれる "extended language range" [RFC4647] を 含む。すなわち、好まれる言語タグは、'Preferred-Value' に現れる各サブタグを順番に含む。この文書の他の箇所で 説明されるように、追加のフィールドを言語タグに含める こともできる。たとえば、祖父化タグ "zh-min-nan"（閩南語） の置換は "nan" であり、これは "nan-Hant" や "nan-TW" などのタグの基礎として使用できる（"zh-nan-Hant" や "zh-nan-TW" のような拡張言語サブタグ形式も使用できる ことに注意されたい）。 Phillips & Davis 最善現行慣行 [ページ 24]
RFC 5646 言語タグ 2009年9月 o 'Prefix' * Prefix の field-body は、このレコードのサブタグに対する可能な 接頭辞の一つとして RECOMMENDED である有効な言語タグを含む。 このフィールドは、'Type' field-body が 'extlang' または 'variant' のいずれかであるレコードに現れてよい（MAY） （それ以外のいかなるレコード型にも現れてはならない （MUST NOT））。 o 'Suppress-Script' * Suppress-Script の field-body は、関連する主言語または拡張 言語サブタグとともに言語タグを形成するために使用すべきで ない（SHOULD NOT）用字サブタグを含む。このフィールドは、 'Type' field-body が 'language' または 'extlang' のレコード にのみ現れなければならない（MUST）。Section 4.1 を参照 されたい。 o 'Macrolanguage' * Macrolanguage の field-body は、ISO 639 により、この言語 サブタグを包含する「マクロ言語」として定義された主言語 サブタグを含む。このフィールドは、'Type' field-body が 'language' または 'extlang' のいずれかであるレコードに のみ現れなければならない（MUST）。 o 'Scope' * Scope の field-body は、ISO 639 に従った言語コードの型を 示す主言語または拡張言語サブタグに関する情報を含む。この フィールドで許可される値は、"macrolanguage", "collection", "special", および "private-use" である。このフィールドは 'Type' field-body が 'language' または 'extlang' のいずれか であるレコードにのみ現れる。このフィールドが省略された 場合、その言語は個別言語である。 o 'Comments' * Comments の field-body は、登録簿を理解し、そのサブタグまたは タグを用いて言語タグを実装するために適切と見なされる、 サブタグに関する追加情報を含む。 この文書の将来の版は、登録簿に追加のフィールドを追加する可能性 がある。実装は、この文書で定義されていない登録簿中のフィールド を無視すべきである（SHOULD）。 Phillips & Davis 最善現行慣行 [ページ 25]
RFC 5646 言語タグ 2009年9月 3.1.3. Type フィールド フィールド 'Type' は、それが現れるレコード型を識別する文字列を 含む。'Type' field-body の値は次のとおりである。"language" （Section 2.2.1）、"extlang"（Section 2.2.2）、"script" （Section 2.2.3）、"region"（Section 2.2.4）、"variant" （Section 2.2.5）、"grandfathered" または "redundant" （Section 2.2.8）。 3.1.4. Subtag および Tag フィールド フィールド 'Subtag' は、レコードで定義されるサブタグを含む。 フィールド 'Tag' は、'Type' が 'grandfathered' または 'redundant' のいずれかであるレコードに現れ、[RFC3066] の下で登録されたタグを 含む。 'Subtag' field-body は、Section 2.1.1 で説明される大文字小文字 慣習に従わなければならない（MUST）。すべてのサブタグは field-body で小文字を使用するが、二つの例外がある。 'Type' フィールドが 'script' であるサブタグ（言い換えれば、 ISO 15924 によって定義されるサブタグ）は titlecase を使用 しなければならない（MUST）。 'Type' フィールドが 'region' であるサブタグ（言い換えれば、 ISO 3166-1 によって定義される非数値地域サブタグ）はすべて 大文字を使用しなければならない（MUST）。 'Tag' field-body は、Section 2.1.1 で説明される規則に従って 書式化されなければならない（MUST）。 3.1.5. Description フィールド フィールド 'Description' は、レコード中のタグまたはサブタグの 説明を含む。'Description' フィールドは、レコードごとに複数回 現れてよい（MAY）。'Description' フィールドは Unicode 文字の 全範囲を含んでよい（MAY）。少なくとも一つの 'Description' フィールドはラテン文字で記述または転写されなければならず （MUST）、追加の 'Description' フィールドは任意の用字または言語 であってよい（MAY）。 'Description' フィールドは識別の目的で使用される。Description は、 あるサブタグを、それと混同される可能性のある他のサブタグから 区別するために必要な情報すべて、かつそれだけを含むべきである （SHOULD）。これは一般的な背景情報を提供したり、考えられるすべて の別名または呼称を提供したりすることを意図しない。 'Description' フィールドは、必ずしもレコード中の項目の実際の 自称名を表すものではなく、またいずれの説明も特定の言語（たと えば英語やフランス語）であることは保証されない。 Phillips & Davis 最善現行慣行 [ページ 26]
RFC 5646 言語タグ 2009年9月 ISO 639、ISO 15924、ISO 3166-1、または UN M.49 コードに対応する 登録簿中の説明は、その識別子が登録簿に追加された時点、または 安定性規則（Section 3.4）の範囲内で後続の登録により変更された 時点で、出典標準によって定義されたその識別子の意味を示すこと だけを意図する。'Description' は出典標準そのものの内容を置き 換えない。'Description' フィールドは、サブタグのローカライズ された英語名となることを意図しない。言語タグおよびサブタグの 説明のローカライズまたは翻訳は、この文書の範囲外である。 出典標準（ISO 639 や ISO 15924 など）から取得されるサブタグに ついては、レコード中の 'Description' フィールドも最初はその出典 標準から取得される。出典標準における複数の説明は、個別の 'Description' フィールドに分割される。出典標準の説明は、挿入前 または登録手続きを通じて編集または変更してよく（MAY）、追加的 または余分な説明は省略または削除してよい。各 'Description' フィールドは、それが現れるレコード内で一意でなければならず （MUST）、同じ説明の書式上の変異は、その特定レコード内に現れる べきではない（SHOULD NOT）。たとえば、ISO 639-1 コード 'fy' は その標準において説明 "Western Frisian" と説明 "Frisian, Western" の両方を持つが、登録簿にはこれらの説明の一つのみが現れる。 利用者がどのサブタグを使用すべきかについて混乱しないようにする ため、任意の特定型（'language', 'extlang', 'script' など）の レコードに割り当てられた 'Description' フィールドは、その所与の レコード型内で一意でなければならない（MUST）。ただし次の例外が ある。特定の 'Description' フィールドが所与の型の複数レコードに 出現する場合、'Deprecated' フィールドを省略できるレコードは 最大一つだけである。同じ 'Description' を共有するすべての非推奨 レコードは同じ 'Preferred-Value' を持たなければならず（MUST）、 すべての非非推奨レコードはその 'Preferred-Value' でなければなら ない（MUST）。これは、同じ型で 'Description' を共有する二つの レコードは意味的にも同等であり、所与の 'Description' について、 その意味に対して好まれるレコードは一つを超えないことを意味する。 たとえば、'language' サブタグ 'zza'（Zaza）と 'diq'（Dimli）を 考える。偶然にも '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 リストに提出する前に、書式上の不規則性 （綴り誤り、不適切なアポストロフィまたはその他の句読点、過剰 または不足した空白など）を修正するために説明を編集してよい （MAY）。 3.1.6. Deprecated フィールド フィールド 'Deprecated' は、そのレコードが非推奨とされた日付を 含み、Section 3.3 で説明する保守手続き、または Section 3.5 で 説明する登録手続きを通じて、任意のレコードに追加、変更、または 削除してよい（MAY）。通常、'Deprecated' フィールドの追加は、 ISO 3166 などの標準化団体がコードを撤回するという作用による。 言語タグでは有効であるものの、'Deprecated' フィールドを含む サブタグおよびタグは非推奨であり、検証処理器はこれらのサブタグ を生成すべきではない（SHOULD NOT）。'Deprecated' フィールドを 含み、対応する 'Preferred-Value' フィールドを持たないレコード には置換写像が存在しないことに注意されたい。 歴史的な事例の中には、元の非推奨日付を再構成できなかったものが ある。そのような場合、登録簿には近似の日付が現れる。一部の サブタグ、および一部の祖父化タグまたは冗長タグは、登録簿の初期 作成以前に非推奨とされた。これに関する厳密な規則は Section 2 of [RFC4645] に現れる。これらのレコードは、対応する 'Added' フィールドよりも早い日付の 'Deprecated' フィールドを 持つことに注意されたい。 3.1.7. Preferred-Value フィールド フィールド 'Preferred-Value' は、それが現れるレコードと別のタグ またはサブタグ（そのレコードの 'Type' による）との間の写像を 含む。このフィールドの値は正準化（Section 4.5 参照）のために 使用される。サブタグまたはタグが 'Deprecated' フィールドも持つ 場合、'Preferred-Value' は、言語タグを選択するときにこの レコードの値を表すための最良の選択として RECOMMENDED である。 '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' フィールドも持たなければならない（MUST）。この フィールドは、そのタグまたはサブタグが好まれる値を優先して非推奨 とされた日付を含む。 型 'extlang' のレコードでは、'Preferred-Value' フィールドは対応 する 'Deprecated' フィールドなしに現れる。実装は、これらの preferred value 写像を無視してよい（MAY）が、写像を無視する場合は 一貫してそうすべきである（SHOULD）。また、'Preferred-Value' を 写像先項目と同等に扱うべきである（SHOULD）。たとえば、タグ "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' は、Section 3.3 の規則に従ってレコードに追加、 変更、または削除してよい（MAY）。レコードにおける 'Preferred-Value' フィールドの追加、変更、または削除は、影響を 受けるサブタグを使用する内容に再タグ付けが必要であることを意味 しない。 型 "grandfathered" および "redundant" のレコードにおける 'Preferred-Value' フィールドは、それぞれ、そのレコードの値に代えて 使用することが強く RECOMMENDED である "extended language range" [RFC4647] を含む。多くの場合、これらの写像は [RFC4646] が採用 される前の期間に、タグの非推奨化を通じて作成された。たとえば、 タグ "no-nyn" は、ISO 639-1 が定義する言語コード 'nn' を優先して 非推奨とされた。 型 "extlang" のサブタグレコードにおける 'Preferred-Value' フィールドも "extended language range" を含む。これにより、 サブタグを単一の主言語サブタグ、または新しい language-extlang 列 のいずれかを優先して非推奨にできる。 通常、サブタグに対する 'Preferred-Value' フィールドの追加、削除、 または変更は、出典標準の一つにおける変更を反映するために行われる。 たとえば、ISO 3166-1 地域コードが別のコードを優先して非推奨と された場合、それは 'Preferred-Value' フィールドの追加をもたらす べきである（SHOULD）。 一つのサブタグへの変更は、他のサブタグにも影響しうる。登録簿への 変更を提案するとき、Language Subtag Reviewer は、そのような影響に ついて登録簿を確認し、Section 3.5 の手続きにより必要な変更を 提案しなければならない（MUST）。ただし、誰でもそのような変更を 要求してよい（MAY）。例: サブタグ 'XX' が 'YY' の 'Preferred-Value' を持つと仮定する。 後に 'YY' が 'ZZ' の 'Preferred-Value' を持つよう変更された 場合、'XX' の 'Preferred-Value' も 'ZZ' に変更されなければ ならない（MUST）。 登録済み言語サブタグ 'dialect' が、ISO 639 のいずれの部分でも まだ利用できない言語を表すと仮定する。後に ISO 639 に対応する 言語コードが追加された場合、それは 'dialect' への 'Preferred-Value' の追加をもたらすべきである（SHOULD）。 Phillips & Davis 最善現行慣行 [ページ 30]
RFC 5646 言語タグ 2009年9月 3.1.8. Prefix フィールド フィールド 'Prefix' は、おそらく他のサブタグとともに、この レコードのサブタグに対する可能な接頭辞の一つとして RECOMMENDED である有効な言語タグを含む。すなわち、少なくとも一つの 'Prefix' を持つ拡張言語または変種サブタグを言語タグに含める場合、結果 として得られるタグは "Extended Filtering" アルゴリズム （[RFC4647] 参照）を用いて、そのサブタグの 'Prefix' フィールドの 少なくとも一つに一致すべきであり（SHOULD）、その 'Prefix' 中の 各サブタグはサブタグ自体の前に現れるべきである（SHOULD）。 'Prefix' フィールドは、型 'extlang' のレコードに正確に一回 現れなければならない（MUST）。'Prefix' フィールドは、型 'variant' のレコードに複数回現れてよく（MAY）、また全く現れなくてもよい。 この型の追加フィールドは、その 'variant' レコードがすでに少なく とも一つの 'Prefix' フィールドを持っている場合に限り、登録手続き を通じて 'variant' レコードへ追加してよい（MAY）。 各 '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'）のそれぞれとともに使用するのに 適していることだけでなく、タグ中でこれらの変種の後に現れるべき である（SHOULD）ことも示す。したがって、言語タグは "sl-1994-rozaj-biske" や "sl-rozaj-1994-biske" ではなく、 "sl-rozaj-biske-1994" の形式を取るべきである。 レコードが 'Prefix' フィールドを含まない場合、'Prefix' フィールド は後日そのレコードに追加してはならない（MUST NOT）。それ以外の 場合、'Prefix' フィールド集合への変更（追加、削除、または修正） は、推奨される言語タグの範囲を厳密に広げる限り登録してよい （MAY）。たとえば、値 "be-Latn"（ベラルーシ語、ラテン文字）を 持つ 'Prefix' は、値 "be"（ベラルーシ語）に置き換えることが できるが、値 "ru-Latn"（ロシア語、ラテン文字）または値 "be-Latn-BY"（ベラルーシ語、ラテン文字、ベラルーシ）に置き換える ことはできない。 Phillips & Davis 最善現行慣行 [ページ 31]
RFC 5646 言語タグ 2009年9月 後者は推奨されるタグの範囲を変更または狭めるためである。 'Prefix' フィールドの field-body は、所与のレコードについてすでに 登録されているいかなる 'Prefix' とも衝突してはならない（MUST NOT）。 このような衝突は、二つのサブタグがそれぞれ相手方のサブタグを 含む 'Prefix' を持つ場合など、その接頭辞を含む有効なタグを構築 できないときに発生する。たとえば、サブタグ 'avariant' が接頭辞 "es-bvariant" を持つと仮定する。このときサブタグ 'bvariant' に 接頭辞 'avariant' を割り当てることはできない。なぜなら、それには "es-avariant-bvariant-avariant" という形式のタグが必要になり、 これは有効ではないからである。 3.1.9. Suppress-Script フィールド フィールド 'Suppress-Script' は、用字サブタグ（そのレコードが登録簿 に現れるもの）を含む。フィールド 'Suppress-Script' は、'Type' field-body が 'language' または 'extlang' のいずれかであるレコード にのみ現れなければならない（MUST）。このフィールドは、レコード中に 複数回現れてはならない（MUST NOT）。 このフィールドは、所与の言語の文書の圧倒的多数を書くために使用 される用字を示す。そのような用字のサブタグは、したがって言語タグ に識別上の情報を追加せず、その言語の大部分の文書では使用すべき ではない（SHOULD NOT）。このフィールドで示される用字サブタグを 省略することは、この文書の規則に従って生成される言語タグと、 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 によって割り当てられた 値のみが包含対象として考慮される。'Macrolanguage' フィールドは、 ISO 639-3 が新しい値を定義したり古い値を撤回したりするたびに、 通常の登録手続きを通じて追加または削除してよい（MAY）。マクロ言語 は情報提供的なものであり、ISO 639-3 が値を変更した場合には削除 または変更してよい（MAY）。このフィールドの使用、およびマクロ言語 と包含言語サブタグの選択に関する詳細については、Section 4.1.1 を参照されたい。 たとえば、言語サブタグ 'nb'（ノルウェー語ブークモール）と 'nn' （ノルウェー語ニーノシュク）は、それぞれ 'no'（ノルウェー語）を値 とする 'Macrolanguage' フィールドを持つ。詳細については Section 4.1 を参照されたい。 3.1.11. Scope フィールド フィールド 'Scope' は、ISO 639 から派生した主言語または拡張言語 サブタグに関する分類情報を含む。ほとんどの言語は 'individual' の scope を持つ。これは、その言語がマクロ言語、集合、特殊コード、 または私用ではないことを意味する。すなわち、通常「一つの言語」と 見なされるものである。'Scope' フィールドを持たない任意の主言語 または拡張言語サブタグは個別言語である。 'Scope' 情報は、ISO 639 内におけるコード割当の目的または「範囲」を 示すため、言語タグを選択するときに有用な場合がある。利用可能な値は 次のとおりである。 o 'macrolanguage' - ISO 639-3 で定義されるマクロ言語を示す （Section 3.1.10 参照）。マクロ言語は、ときに単一言語と見なされる 密接に関連した言語の集合である。 o 'collection' - 言語の集合を表すサブタグを示す。通常、何らかの 歴史的、地理的、または言語学的関連による集合である。マクロ言語 とは異なり、集合は緩く関連するだけの言語を含むことができ、その 集合に属する言語と互換的に使用することはできない。 Phillips & Davis 最善現行慣行 [ページ 33]
RFC 5646 言語タグ 2009年9月 o 'special' - 特殊言語コードを示す。これらは、具体的な言語に特に 関連しない言語的属性を識別するために使用されるサブタグである。 これには、言語が未確定である場合や非言語的内容のためのコードが 含まれる。 o 'private-use' - 基礎となる標準において私用として予約されたコードを 示す。この scope を持つサブタグは、ISO 639 または登録済みの割当が 存在しない主言語を示すために使用できる。 'Scope' フィールドは、型 'language' または 'extlang' のレコードに 現れてよい（MAY）。拡張言語サブタグの接頭辞の多くは 'macrolanguage' の 'Scope' を持つ（ただし、そうでないものもある） こと、また 'macrolanguage' の 'Scope' を持つ多くの言語には、それに 関連付けられた拡張言語サブタグがあることに注意されたい。 'Scope' フィールドは、その変更が ISO 639 による割当の分類変更を 反映する場合、登録手続きを通じて追加、変更、または削除してよい （MAY）。このような変更はまれであると期待される。 たとえば、主言語サブタグ 'zh'（中国語）は 'macrolanguage' の 'Scope' を持つ一方、その包含言語 'nan'（閩南語）は 'individual' の 'Scope' を持つ。特殊値 'und'（Undetermined）は 'special' の 'Scope' を持つ。ISO 639-5 の集合 'gem'（ゲルマン諸語）は 'collection' の 'Scope' を持つ。 3.1.12. Comments フィールド フィールド 'Comments' は、レコードに関する追加情報を含み、レコード ごとに複数回現れてよい（MAY）。field-body は Unicode 文字の全範囲を 含んでよく（MAY）、特定の用字に制限されない。このフィールドは登録 手続きを通じて挿入または変更してよく（MAY）、安定性の保証は提供 されない。 このフィールドの内容は、情報を登録する必要性、要求の適切性、および 合理的で実用的なサイズ制限を除き、制限されない。'Comments' フィールド の主な理由はサブタグ識別であり、使用の助けとして、そのサブタグを 混同される可能性のある他のサブタグから区別することにある。サブタグの 使用、歴史、または一般的背景に関する大量の情報は、通常、登録簿では なく登録要求に属するため、好ましくない。 Phillips & Davis 最善現行慣行 [ページ 34]
RFC 5646 言語タグ 2009年9月 3.2. 言語サブタグ審査者 Language Subtag Reviewer は、ietf-languages@iana.org メーリング リストを司会し、登録要求に応答し、Section 3.3 で説明される その他の登録簿保守作業を行う。Language Subtag Registry の レコードを変更、更新、または追加するよう IANA に要求することを 許されているのは、Language Subtag Reviewer だけである。 Language Subtag Reviewer は、必要に応じてリストの司会および その他の事務作業を委任してよい（MAY）。 Language Subtag Reviewer は、IESG によって無期限の任期で任命 され、IESG の裁量により解任または交代の対象となる。IESG は （この文書の採用時または空席発生時に）その職の候補者を募集し、 その後、候補者の資格について意見を募集する。適格な候補者は BCP 47 とその要件に精通しているべきであり、登録手続きを 公平に、応答性をもって、かつ慎重に管理する意思があり、また 審査者が主張を評価し、言語専門家およびサブタグ要求者の貢献を 利用できるよう、言語識別の問題について十分な知識を持つべきで ある。 Language Subtag Reviewer のその後の遂行または決定は、他の IETF 決定と同じ規則の下で IESG に不服申し立てしてよい（MAY） （[RFC2026] 参照）。IESG は Language Subtag Reviewer の決定を 取り消し、覆し、指針を提供し、またはその他の適切な措置を取る ことができる。 3.3. 登録簿の保守 登録簿の保守では、ISO 639、ISO 15924、ISO 3166、および UN M.49 によりコードが割り当てられ、または撤回されるたびに、Language Subtag Reviewer が各変更を評価し、この文書の規則に従って適切な 対応方針を決定しなければならない（MUST）。そのような更新は Section 3.5 で説明される登録手続きに従う。通常、Language Subtag Reviewer は登録フォームに記入し、それを提出することに よって、新規または更新されたレコードの手続きを開始する。これら の標準の一つに変更が生じ、Language Subtag Reviewer が適時に これを行わない場合、任意の利害関係者がそのフォームを提出して よい（MAY）。その後、登録手続きは通常どおり継続する。 一部の登録は、地域サブタグが新しい値を優先して非推奨にされる 場合など、他のサブタグ、場合によっては複数のサブタグに影響を 与えることに注意されたい。Language Subtag Reviewer は、そのような 変更が適切に登録されることを確保する責任を負い、各変更には それぞれ独自の登録フォームが必要である。 Phillips & Davis 最善現行慣行 [ページ 35]
RFC 5646 言語タグ 2009年9月 Language Subtag Reviewer は、新しいサブタグがこの文書の他の箇所 （特に Section 3.4）の要件を満たすことを確保しなければならず （MUST）、またはその節で説明されるように代替サブタグのための 適切な登録フォームを提出しなければならない。変更の影響を受ける 各個別サブタグは、それぞれ独自の登録フォームとともに、別個の メッセージで ietf-languages@iana.org リストへ送信されなければ ならない（MUST）。 3.4. IANA 登録簿エントリの安定性 登録簿中のエントリおよびその意味の安定性は、言語タグの長期的な 安定性にとって重要である。この節の規則は、特定の言語タグの意味 が長期にわたって安定し、変更されないことを保証する。 これらの規則は、ISO 639、ISO 15924、ISO 3166、および UN M.49 に よって保守されるコードへの変更（コードの撤回および非推奨化を 含む）が IANA Language Subtag Registry にどのように反映されるか を具体的に扱う。IANA Language Subtag Registry への割当は、次の 安定性規則に従わなければならない（MUST）。 1. 'Type', 'Subtag', 'Tag', および 'Added' フィールド中の値は 変更してはならず（MUST NOT）、長期にわたって安定している ことが保証される。 2. 'Preferred-Value' および 'Deprecated' フィールド中の値は、 登録手続きを通じて追加、変更、または削除してよい（MAY）。 これらの変更は、基礎となる標準（ISO 639、ISO 15924、 ISO 3166-1、または UN M.49）の一つにおける変更を反映する ために必要な変更に限定されるべきであり（SHOULD）、通常、 'Preferred-Value' の変更または削除は特に地域コードに限定 される。 3. 'Description' フィールド中の値は、既存のタグを無効にする ような方法で変更してはならない（MUST NOT）。説明は、範囲を 多少広げたり、情報を追加するよう変更したり、最も一般的な 現代の用法に適合させたりしてよい（MAY）。たとえば、国は ときどき名称を変更する。この歴史的な例として、"Upper Volta" から "Burkina Faso" への変更がある。 4. 型 'variant' の既存レコードには、その 'variant' がすでに 少なくとも一つの 'Prefix' を持つ場合に限り、登録手続きを 通じて 'Prefix' フィールド中の値を追加してよい（MAY）。 既存の 'Prefix' フィールドを持たないいかなる 'variant' にも、 'Prefix' フィールドを登録してはならない（SHALL NOT）。 変種レコードに接頭辞が追加される場合、'Comment' フィールド を使用して、各種接頭辞による異なる用法を説明してよい（MAY）。 Phillips & Davis 最善現行慣行 [ページ 36]
RFC 5646 言語タグ 2009年9月 5. 型 'variant' のレコードにおける 'Prefix' フィールド中の値も、 その変更が接頭辞の集合を広げる限り、変更してよい（MAY）。 すなわち、接頭辞はそれ自身の接頭辞の一つで置き換えてよい （MAY）。たとえば、接頭辞 "en-US" は "en" で置き換える ことができるが、接頭辞 "en-Latn", "fr", または "en-US- boont" で置き換えることはできない。これらの接頭辞値の 一つが必要である場合、それは別個に登録されなければならない。 6. 型 'extlang' のレコードにおける 'Prefix' フィールド中の値は、 追加、変更、または削除してはならない（MUST NOT）。 7. 'Prefix' フィールドは、それが現れるいかなるレコードからも 削除してはならない（MUST NOT）。このフィールドは、型 'variant' の任意のレコードの初期登録に含めるべきであり （SHOULD）、型 'extlang' の任意のレコードには含めなければ ならない（MUST）。 8. 'Comments' フィールドは、登録手続き、またはこの節で説明される 任意の手続きもしくは考慮事項を通じて、追加、変更、修正、 または削除してよい（MAY）。 9. 'Suppress-Script' フィールドは、登録手続きを通じて追加または 削除してよい（MAY）。 10. 'Macrolanguage' フィールドは、登録手続きを通じて追加または 削除してよい（MAY）が、ISO 639 による変更への応答としてのみ である。'Macrolanguage' フィールドは、ある言語が ISO 639 に 対応するマクロ言語を持つ場合に現れる。すなわち、登録簿中の 'Macrolanguage' フィールドは ISO 639 のものと正確に一致する。 その他のマクロ言語写像は登録対象として考慮されない。 11. 'Scope' フィールドは、初期登録後に主言語または拡張言語 サブタグから追加または削除してよく（MAY）、ISO 639 による 任意の変更に一致させるために変更してよい（MAY）。'Scope' フィールドへの変更は、ISO 639 による変更を反映しなければ ならない（MUST）。レコードが 'Scope' フィールドを含まない 主言語または拡張言語サブタグ（すなわち、その大部分）は、 Section 3.1.11 で説明される個別言語であることに注意されたい。 12. 主言語および拡張言語サブタグ（登録手続きを使用して作成された 独立登録値を除く）は、ISO 639 の各部分の割当に従って、次の ように作成される。 A. 既存の 2 文字主言語サブタグと衝突せず、登録簿で定義 された対応する 3 文字主言語を持たない ISO 639-1 によって 割り当てられたコードは、型 'language' の新規レコード として IANA 登録簿に入力される。 Phillips & Davis 最善現行慣行 [ページ 37]
RFC 5646 言語タグ 2009年9月 ISO 639-1 コードを与えられた言語は、マクロ言語に包含 される場合であっても、拡張言語サブタグを与えられない ことに注意されたい。 B. 既存の 3 文字主言語サブタグと衝突せず、ISO 639-1 コード が割り当てられていない（または割り当てられる見込みの ない）ISO 639-3 または ISO 639-5 によって割り当てられた コードは、型 'language' の新規レコードとして IANA 登録簿 に入力される。これら二つの標準は現在、ISO 639-2 コード の上位集合を構成していることに注意されたい。登録時点で 定義済みの 'macrolanguage' 写像を持つコードは、 'Macrolanguage' フィールドを含まなければならない（MUST）。 C. ISO 639-3 によって割り当てられたコードは、拡張言語 サブタグ登録のために考慮してもよい（MAY）。'extlang' レコードが提案される場合であっても、それらには型 'language' の主言語サブタグレコードを割り当てなければ ならない（MUST）ことに注意されたい。拡張言語サブタグの 割当を検討するとき、次の基準が適用される。 1. ある言語がマクロ言語写像を持ち、そのマクロ言語が 拡張言語サブタグを割り当てられた他の包含言語を持つ 場合、新しい言語にも 'extlang' レコードが割り当て られるべきである（SHOULD）。たとえば、マクロ言語が 'zh' または 'ar' である任意の言語には 'extlang' レコードが割り当てられる。 2. マクロ言語に包含される他の言語が 'extlang' レコードも 含まない場合、その言語について 'Extlang' レコードを 作成すべきではない（SHOULD NOT）。たとえば、新しい セルビア・クロアチア語（'sh'）が登録された場合、 セルビア語（'sr'）などの他の包含言語が登録簿にそれを 含まないため、extlang レコードは取得しない。 3. 手話は、'sgn' の 'Prefix' を持つ 'extlang' レコードを 持つべきである（SHOULD）。 4. 登録簿にすでに存在する項目について 'Extlang' レコード を作成してはならない（MUST NOT）。拡張言語サブタグは 初期登録時にのみ考慮される。 5. 拡張言語サブタグレコードは、Section 2.2.2 で説明される とおりに割り当てられたフィールド値を持つ 'Prefix' および 'Preferred-Value' フィールドを含まなければ ならない（MUST）。 D. ISO 639-2 によって割り当てられ、既存の 3 文字主言語または 拡張言語サブタグと衝突せず、ISO 639-1 の 2 文字コードが Phillips & Davis 最善現行慣行 [ページ 38]
RFC 5646 言語タグ 2009年9月 割り当てられていないその他の任意のコードは、型 'language' の新規レコードとして IANA 登録簿に入力される。この種の 登録は将来発生することを想定していない。 13. ISO 15924 および ISO 3166-1 によって割り当てられたコードで、 関連する型の既存サブタグと衝突せず、その意味が同じ型の既存 サブタグと同じでないものは、新規レコードとして IANA 登録簿 に入力される。 14. ISO 639、ISO 15924、または ISO 3166-1 によって割り当てられ、 それぞれの保守機関または登録機関により撤回されたコードは、 言語タグにおいて有効なままである。撤回の日付を含む 'Deprecated' フィールドをレコードに追加しなければならない （MUST）。同じ型の新規レコードが置換値を表すものとして追加 される場合、'Preferred-Value' フィールドも追加してよい （MAY）。登録手続きを使用して、それぞれの標準によるコードの 撤回に関するコメントを追加してよい（MAY）。 例: 地域コード 'TL' は国 'Timor-Leste' に割り当てられ、 コード 'TP'（ポルトガルの統治下にあったときの 'East Timor' に割り当てられていた）を置き換えた。サブタグ 'TP' は言語 タグにおいて有効なままであるが、そのレコードは 'TL' の 'Preferred-Value' を含み、その 'Deprecated' フィールドは 新しいコードが割り当てられた日付（'2004-07-06'）を含む。 15. ISO 639、ISO 15924、または ISO 3166-1 によって割り当てられた コードで、非推奨サブタグを含む関連型の既存サブタグと衝突 するものは、登録簿に入力してはならない（MUST NOT）。再割当 されたサブタグ値には、次の追加的な考慮事項が適用される。 A. ISO 639 コードについて、新たに割り当てられたコードの意味が IANA 登録簿中のサブタグで表されていない場合、Language Subtag Reviewer は、Section 3.5 で説明されるように、 実用上可能な限り速やかに、新しいコードの代替値として 登録済み言語サブタグを IANA 登録簿に入力するための提案を 準備しなければならない（SHALL）。登録済み言語サブタグの 形式は Language Subtag Reviewer の裁量に委ねられ、この文書 における言語サブタグに関するその他の制限に適合しなければ ならない（MUST）。 B. 意味が外部標準（すなわち ISO 639、ISO 15924、ISO 3166-1、 または UN M.49）に由来するすべてのサブタグについて、既存 コードに新しい意味が割り当てられ、その新しい意味がその コードの意味を広げる場合、関連するサブタグの意味はそれに 一致するよう変更してよい（MAY）。 Phillips & Davis 最善現行慣行 [ページ 39]
RFC 5646 言語タグ 2009年9月 ただし、サブタグの意味を狭めてはならない（MUST NOT）。 これは、既存のサブタグ使用の未知の割合が無効になる結果を もたらしうるためである。注記: ISO 639 登録機関（RA）は 類似の安定性方針を採用している。 C. ISO 15924 コードについて、新たに割り当てられたコードの 意味が IANA 登録簿中のサブタグで表されていない場合、 Language Subtag Reviewer は、Section 3.5 で説明される ように、実用上可能な限り速やかに、新しいコードの代替値 として登録済み変種サブタグを IANA 登録簿に入力するための 提案を準備しなければならない（SHALL）。登録済み変種 サブタグの形式は Language Subtag Reviewer の裁量に委ね られ、この文書における変種サブタグに関するその他の制限に 適合しなければならない（MUST）。 D. ISO 3166-1 コードについて、新たに割り当てられたコードの 意味が別の 'region' サブタグと同じ UN M.49 コードに関連 付けられる場合、既存の地域サブタグがその地域に対する 好まれる値として残り、新しいエントリは作成されない。 新しい ISO 3166-1 コードとの関係を示すコメントを、既存の 地域サブタグに追加してよい（MAY）。 E. ISO 3166-1 コードについて、新たに割り当てられたコードの 意味が既存の地域サブタグによって表されていない UN M.49 コードに関連付けられる場合、Language Subtag Reviewer は、 Section 3.5 で説明されるように、適切な UN M.49 国コードを IANA 登録簿のエントリとして入力するための提案を準備しなけ ればならない（SHALL）。 F. ISO 3166-1 コードについて、関連する UN 数値コードがない 場合、Language Subtag Reviewer は UN にその作成を請願しなけ ればならない（SHALL）。要求送信から 90 日以内に UN から応答が ない場合、Language Subtag Reviewer は、実用上可能な限り速やか に、新しいコードの代替値として登録済み変種サブタグを IANA 登録簿に入力するための提案を準備しなければならない（SHALL）。 登録済み変種サブタグの形式は Language Subtag Reviewer の 裁量に委ねられ、この文書における変種サブタグに関するその他 の制限に適合しなければならない（MUST）。この状況が発生する 可能性は極めて低い。 16. UN M.49 は、「国および地域」（ドイツを表す '276' など）と 「地理的地域および小地域」（ヨーロッパを表す '150' など）の 両方についてコードを持つ。対応する ISO 3166-1 コードが存在 しない UN M.49 の国または地域コードは、既存サブタグにより 登録が妨げられる ISO 3166-1 コードの代替としての場合を除き、 登録してはならない（MUST NOT）。 Phillips & Davis 最善現行慣行 [ページ 40]
RFC 5646 言語タグ 2009年9月 そのようなコードが必要になった場合、まず ISO 3166-1 の保守 機関にその地域へコードを割り当てるよう請願しなければならない （SHALL）。ISO 3166-1 によるコード割当の請願が拒否されたか、 適時に処理されなかった場合、その後、Section 3.5 で説明される 登録手続きを使用して、対応する UN M.49 コードを登録できる。 このようにして、ISO 3166-1 が登録簿中の非推奨値を再割当 する場合に、UN M.49 コードは最後の手段として利用可能な値で あり続ける。 17. 冗長エントリおよび祖父化エントリは、合わせて [RFC3066] の下で 登録されたタグの完全な一覧を形成する。冗長タグは、以前に 登録されたタグのうち、現在では登録簿で定義されるサブタグを 使用して形成できるものである。祖父化エントリには、'irregular' であるため決して正当になりえないもの（すなわち、図 1 の 'langtag' 生成規則に一致しないもの）、規則によって制限される もの（'nyn' や 'min' のようなサブタグは extlang 生成規則の ように見えるが、拡張言語サブタグとして登録できない）、または そのサブタグが登録に適切でないものが含まれる。すべての 祖父化タグは ABNF の 'regular' または 'irregular' 生成規則の いずれかに列挙されている。[RFC4646] の下では、祖父化タグが 冗長になることが可能であった。しかし、この可能性があった すべてのタグは、この文書が作成される前に冗長になった。 したがって、冗長タグおよび祖父化タグの集合は現在、恒久的 かつ不変である。いずれの型の新規エントリも追加してはならず （MUST NOT）、既存エントリを削除してはならない（MUST NOT）。 どのタグが当初祖父化され、どのタグが冗長にされたかに関する 意思決定手続きは [RFC4645] で説明されている。 祖父化タグの多くは非推奨である。実際、それらは [RFC4646] 以前から非推奨であった。たとえば、タグ "art-lojban" は主言語 サブタグ 'jbo' を優先して非推奨とされた。これらのタグは、 その一部のサブタグを 'variants' として登録することにより 'redundant' にできた可能性がある。祖父化登録中の 'variant- like' サブタグは、類似または同一の意味を持つ場合であっても、 将来登録してはならない（SHALL NOT）。 3.5. サブタグの登録手続き ここで示される手続きは、現在 IANA Language Subtag Registry に 存在しないサブタグを使用したい者、またはこの文書で許可される 既存レコード中の情報を追加、変更、更新、または削除したい者に よって使用されなければならない（MUST）。 新しいサブタグの独立登録として考慮されるのは、型 'language' および 'variant' のサブタグだけである。安定性のために必要な サブタグ、およびこの文書で定義される制限内で登録簿を ISO 639、 Phillips & Davis 最善現行慣行 [ページ 41]
RFC 5646 言語タグ 2009年9月 ISO 15924、ISO 3166、および UN M.49 と同期させるために必要な サブタグも、Section 3.3 で説明され、Section 3.4 で説明される 安定性規定に従うものとして、この手続きを使用する。 登録要求は、Section 3.4 で説明されるように、サブタグのレコード 中の 'Comments', 'Deprecated', 'Description', 'Prefix', 'Preferred-Value', 'Macrolanguage', または 'Suppress-Script' フィールド中の情報に関して受け付けられる。IANA 登録簿中のその他 すべてのフィールドへの変更は許可されない。 新しいサブタグの登録、または既存のタグもしくはサブタグへの変更 要求は、要求者が下に再掲される登録フォームに記入することから 始まる。各応答はサイズに制限されないため、要求は登録を十分に 説明できることに注意されたい。"Record Requested" 節のフィールド は、レコードが承認される前に Section 3.1 の要件に従う必要がある。 LANGUAGE SUBTAG REGISTRATION FORM 1. Name of requester: 2. E-mail address of requester: 3. Record Requested: Type: Subtag: Description: Prefix: Preferred-Value: Deprecated: Suppress-Script: Macrolanguage: Comments: 4. Intended meaning of the subtag: 5. Reference to published description of the language (book or article): 6. Any other relevant information: 図 5: 言語サブタグ登録フォーム 記入済み登録フォームの例は Appendix B にある。承認済み登録 フォームの完全な一覧は http://www.iana.org を通じてオンラインで 入手できる。読者は、Language Tag Registry は現在廃止されており、 代わりに Language Subtag Registry を参照すべきであることに注意 されたい。 Phillips & Davis 最善現行慣行 [ページ 42]
RFC 5646 言語タグ 2009年9月 サブタグ登録フォームは <ietf-languages@iana.org> に送信され なければならない（MUST）。登録要求は、承認され IANA に提出されて 登録簿に含められる前に、2 週間のレビュー期間を受ける。登録手続き の過程で要求に変更が加えられた場合（Section 3.1 の要件を満たす ための修正、または所与のレコード型について 'Description' フィールドを一意にするための修正など）、変更後のフォームも IANA への提出の少なくとも 1 週間前に <ietf-languages@iana.org> に 送信されなければならない（MUST）。 ietf-languages リストは公開リストであり、 <ietf-languages-request@iana.org> に要求を送信することで参加 できる。このリストは IESG の要求により、IANA または任意の第三者 によってホストできる。 IANA に登録を転送する前に、Language Subtag Reviewer は、この文書 中のすべての要件が満たされていることを確保しなければならない （MUST）。これには、'Subtag' フィールド中の値が Section 3.1.4 の説明に従った大文字小文字に一致すること、および Section 3.1.5 で説明されるように 'Description' フィールドが所与のレコード型 について一意であることを確保することが含まれる。Reviewer はまた、 登録簿を更新するときに IANA を支援するため、適切な File-Date レコードが要求に含まれることを確保しなければならない（MUST） （Section 5.1 参照）。 登録フォームおよび登録簿レコード自体の両方における一部の フィールドは、非 ASCII 文字の使用を許可する。登録要求は、一貫性 と明確性のため UTF-8 符号化を使用すべきである（SHOULD）。しかし、 一部のメールクライアントはこの符号化をサポートしないため、登録 要求には他の符号化を使用してよい（MAY）。Language Subtag Reviewer は、保管される要求フォームおよび登録簿レコードの両方に適切な Unicode 文字が現れることを確保する責任を負う。IANA による転写 または符号化エラーの場合、Language Subtag Reviewer は、IANA を 支援するために必要な情報を提供して、登録簿の修復を要求する。 拡張言語サブタグ（型 'extlang'）は、定義上、常に別の言語に包含 される。したがって、型 'extlang' のすべてのレコードは、登録時に 'Prefix' フィールドを含まなければならない（MUST）。この 'Prefix' フィールドは決して変更または削除できず、そのような要求は拒否 されなければならない（MUST）。 変種サブタグは通常、特定範囲の言語タグとともに使用するために登録 され、その適用対象となる言語の用語に基づく変種サブタグが推奨 される。たとえば、サブタグ 'rozaj'（レジア方言）は、レジア方言が スロベニア語の方言であるため、主言語サブタグ "sl"（スロベニア語） で始まる言語タグとともに使用することを意図している。したがって、 サブタグ 'rozaj' は "sl-Latn-rozaj" または "sl-IT-rozaj" などの タグで適切である。この情報は登録簿の 'Prefix' フィールドに格納 される。変種 Phillips & Davis 最善現行慣行 [ページ 43]
RFC 5646 言語タグ 2009年9月 登録要求は、登録フォームに少なくとも一つの 'Prefix' フィールドを 含めるべきである（SHOULD）。 既存のサブタグ値を持つ所与の型の追加レコードを割り当てる要求は、 拒否されなければならない（MUST）。たとえば、変種サブタグ 'rozaj' はすでに登録簿に存在するため、サブタグ 'rozaj' を持つ型 'variant' の第二のレコードを追加することは禁止される。 所与の登録済み変種サブタグの 'Prefix' フィールドは、使用の手引き として IANA 登録簿に存在する。追加の 'Prefix' フィールドは、追加 登録フォームを提出することにより追加してよい（MAY）。そのフォーム では、"Any other relevant information:" フィールドが、それが接頭辞の 追加であることを示さなければならない（MUST）。 異なる意味を暗示する 'Prefix' フィールドを変種サブタグに追加する 要求は、拒否すべきである（SHOULD）。たとえば、タグ "de-1994" が 何らかのドイツ語方言または正書法形式を表すように、サブタグ '1994' に接頭辞 "de" を追加する要求は拒否される。'1994' サブタグは特定の スロベニア語正書法を表し、追加登録はそのサブタグに割り当てられた 意味を変更または曖昧にすることになる。代わりに別個のサブタグを 提案すべきである（SHOULD）。 現在 'Prefix' フィールドを持たない変種サブタグへ 'Prefix' を追加 する要求は、拒否されなければならない（MUST）。変種が接頭辞なしで 登録されるのは、それらが多くの、またはすべての言語で潜在的に 有用であるためである。一つ以上の 'Prefix' フィールドを追加する ことは、サブタグの範囲を劇的に狭めるため、その変種の使用に潜在的 に有害である（これは安定性規則（Section 3.4）の下で許可されない） のに対し、通常 'Prefix' の追加が行うのはサブタグの範囲を広げる ことである。そのような「接頭辞なし」変種の例はサブタグ 'fonipa' であり、これは International Phonetic Alphabet、すなわち多くの 言語を転写するために使用できる方式を表す。 要求で提供される 'Description' フィールドは、ラテン文字で記述 または転写された説明を少なくとも一つ含まなければならない（MUST）。 要求はまた、任意の用字または言語による追加の 'Description' フィールドを含んでよい（MAY）。'Description' フィールドは識別目的 で使用され、必ずしもその言語または変異の実際の自称名を表すもの ではない。また、特定の言語である必要もないが、レコード中の項目を 識別するために適切かつ十分であるべきである（SHOULD）。Language Subtag Reviewer は、提案された任意の 'Description' フィールドを 確認および編集し、一意性を確保し、同じ型の他のレコード中の 'Description' フィールドとの衝突を防ぐ。これが独立登録要求で 発生した場合、Language Subtag Reviewer は、要求の唯一の目的が 重複する 'Description' フィールドを導入することである場合を除き、 Section 3.5 で説明されるように、議論に起因する要求の変更として レコードを <ietf-languages@iana.org> に再提出しなければならない （MUST）。その場合、要求は拒否されなければならない（SHALL）。 Phillips & Davis 最善現行慣行 [ページ 44]
RFC 5646 言語タグ 2009年9月 'Description' フィールドは安定していることが保証されない。意図の 修正または明確化は、可能な変更の例である。登録簿中のエントリの 翻訳または転写を提供しようとする試み（定義上、新しい情報を何も 提供しない）は、承認される可能性が低い。 2 週間のレビュー期間が経過して間もなく、Language Subtag Reviewer は次のいずれかの措置を取らなければならない（MUST）。 o 要求を明示的に受理し、Section 3.3 で説明される手続きに従って、 挿入または変更されるレコードを含むフォームを <iana@iana.org> へ転送する。 o リスト上で提起された重大な異議、またはこの文書中の制約に関する 問題（明示的に引用されなければならない（MUST））により、要求を 明示的に拒否する。 o さらなる議論を許可するため、追加の 2 週間単位を与えてレビュー 期間を延長する。各 2 週間単位の後、Language Subtag Reviewer は、 その登録が受理、拒否、または延長されたかをリスト上で示さなけれ ばならない（MUST）。 Language Subtag Reviewer は望むならリスト上で異議を提起してよい （MAY）ことに注意されたい。重要なのは、その異議が公に行われなけれ ばならない（MUST）ことである。 ときには、レビュー期間中の議論の結果、またはこの文書中の要件に よって、要求を変更する必要がある。申請者、Language Subtag Reviewer、 または他の者は、記入済み登録フォームの変更版を提出してよく（MAY）、 それは申請者の明示的な承認を得て、元の要求に代えて検討される。 そのような変更は 2 週間の議論期間を再開始しないが、IANA に提出 される最終レコードを含む申請は、Language Subtag Reviewer がその レコードを IANA に転送する少なくとも 1 週間前にリスト上に現れなけ ればならない（MUST）。申請者は、拒否された申請をより適切な情報 または追加情報で変更し、再提出してよい（MAY）。これは新しい 2 週間のコメント期間を開始する。 Section 3.3 または Section 3.4 の規定により開始された登録は、 （最終的には登録簿に現れなければならないため）完全に拒否しては ならず（SHALL NOT）、可能な限り速やかに完了すべきである（SHOULD）。 レビュー手続きにより、リストメンバーはフォーム中の具体的な情報と それが含むレコードについてコメントでき、 Phillips & Davis 最善現行慣行 [ページ 45]
RFC 5646 言語タグ 2009年9月 したがって、それが正確かつ一貫していることを確保する助けとなる。 Language Subtag Reviewer はフォームの特定版を拒否してよい（MAY）が、 上述のようにレビュー期間を延長しながら、そのフォームが審査者の 承認に値する形式となり、リストのラフコンセンサスを満たすまで、 適切な置換案を提案しなければならない（MUST）。 Language Subtag Reviewer によって行われた決定は、他の IETF 決定 [RFC2026] と同じ規則の下で IESG [RFC2028] に不服申し立てして よい（MAY）。これには、レビュー期間を延長する決定、または明確 かつ適時に決定を発表しないことが含まれる。 承認済みレコードは Language Subtag Registry に現れる。承認済み 登録フォームは http://www.iana.org からオンラインで入手できる。 既存レコードへの更新または変更は、新規登録と同じ手続きに従う。 Language Subtag Reviewer は、2 週間のレビュー期間の後、その登録を 更新するコンセンサスがあるかどうかを決定する。通常、元の登録者に よる異議は、そのようなコンセンサスを形成するうえで特別な重みを 持つ。 登録は恒久的かつ安定している。一度登録されると、サブタグは登録簿 から削除されず、特定の言語または変種を指定する有効な方法であり 続ける。 注記: 登録フォームにおける "Reference to published description" 節の 目的は、ある言語が登録されているか、または特定のサブタグがどの 言語または言語変異を指すかを検証する助けとなることである。多くの 場合、その言語の権威ある文法書または辞書への参照が有用である。 そのような著作が存在しない場合、その言語を説明する、またはその 言語で書かれた他のよく知られた著作が適切な場合がある（MAY）。 Language Subtag Reviewer は、何が「十分に良い」参考資料であるかを 決定する。この要件は、話者人口の規模や標準化された正書法の欠如に よって、特定の言語または方言を除外することを意図していない。 少数言語は、それ自体の価値に基づいて同等に考慮される。 3.6. 登録の可能性 サブタグまたはサブタグに関する情報の登録の可能性には、次が含まれる。 o ISO 639 に列挙されておらず、列挙または登録された言語の変種で ない言語の主言語サブタグは、登録してよい（MAY）。この文書が 作成された時点では、この形式のサブタグの例は存在しなかった。 言語サブタグを登録しようとする前に、その言語を ISO 639 に登録 しようとする試みがなければならない（MUST）。 Phillips & Davis 最善現行慣行 [ページ 46]
RFC 5646 言語タグ 2009年9月 ISO 639-1、ISO 639-2、または ISO 639-3 に存在するコードによって 定義される言語、ISO 639 登録機関により検討中の言語、またはそれら の機関へ登録を試みたことがない言語については、サブタグを登録 してはならない（MUST NOT）。ISO 639 が以前にある言語の登録を拒否 した場合、その言語が IANA 登録簿で主言語サブタグとして登録される には、追加の非常に説得力のある必要性の証拠がなければならないと 仮定するのが合理的である（この型のサブタグが登録される可能性は 極めて低い程度に）。 o 言語内の方言またはその他の区分もしくは変異、その正書法、書記体系、 地域的または歴史的用法、翻字またはその他の変換、または識別上の 変異は、変種サブタグとして登録してよい（MAY）。例として、'rozaj' サブタグ（スロベニア語のレジア方言）がある。 o Section 3.1 で説明されるように、タグまたはサブタグレコード中の フィールド（一般に情報提供的な性質を持つもの）の追加または保守は 許可される。そのような変更は Section 3.4 の安定性規定に従う。 これには、廃止または撤回されたコードに対する 'Description', 'Comments', 'Deprecated', および 'Preferred-Value' フィールド、 または主言語サブタグへの 'Suppress-Script' もしくは 'Macrolanguage' フィールドの追加、ならびに変種サブタグへの適切な 'Prefix' フィールドの追加など、この文書で許可されるその他の変更 が含まれる。 o Section 3.4 で説明されるように、ISO 639、ISO 15924、ISO 3166-1、 および UN M.49 による割当を反映するために必要なレコードの追加 および関連するフィールド値の変更は許可される。 登録が提案されたサブタグが祖父化タグの全部または一部を冗長に するが、その意味が祖父化タグの意味と衝突する、またはそれを変更 する場合、その提案は拒否されなければならない（MUST）。 この文書は、どのサブタグまたはサブタグへの変更が適切であるか （または適切でないか）の決定を、Section 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 Phone: +43 1 26 75 35 Ext. 312 Fax: +43 1 216 32 72 ISO 639-2 は、ISO 639-2 における言語一覧への追加および変更のための 登録機関を定義している。この機関は次のとおりである。 Library of Congress Network Development and MARC Standards Office Washington, DC 20540, USA Phone: +1 202 707 6237 Fax: +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 Phone: +1 972 708 7400, ext. 2293 Fax: +1 972 708 7546 Email: 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 Phone: +1 202 707 6237 Fax: +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 Phone: +41 22 749 72 33 Fax: +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 United Nations Secretariat の Statistics Division は Standard Country or Area Codes for Statistical Use を保守しており、次で連絡できる。 Statistical Services Branch Statistics Division United Nations, Room DC2-1620 New York, NY 10017, USA Fax: +1-212-963-0623 Email: statistics@un.org URL: http://unstats.un.org/unsd/methods/m49/m49alpha.htm 3.7. 拡張と拡張登録簿 拡張サブタグとは、'x' 以外の単一文字サブタグ（"singletons"）に よって導入されるサブタグである。これらは、言語構成要素を含み、 言語タグを理解するアプリケーションと互換性のある識別子の生成の ために予約されている。 拡張の構造および形式は、将来 singletons を使用して作成される 可能性のあるアプリケーションと前方互換な実装を作成できるように、 この文書によって定義される。さらに、singletons を保守するための 機構を定義することは、将来の改訂または更新が必要になる可能性を 低減することによって、この文書に安定性を与える。 単一文字サブタグは、[RFC5226] によって定義される "IETF Review" 方針を使用して IANA により割り当てられる。この方針は RFC の作成 を要求し、その RFC はサブタグを保守するための名称、目的、過程、 および手続きを定義しなければならない（SHALL）。保守または登録 機関は、名称、連絡先メール、議論リストメール、および登録簿の URL 所在地を含め、RFC 中で明確に示されなければならない（MUST）。 RFC は、次の各項目を指定または含めなければならない（MUST）。 o 仕様は、その作成を支配するこの文書の特定のバージョンまたは 改訂を参照しなければならず（MUST）、この文書のこの節を参照 しなければならない（MUST）。 o 仕様および仕様によって定義されるすべてのサブタグは、この文書 で定義されるタグおよびサブタグの形成に関する ABNF およびその他 の規則に従わなければならない（MUST）。特に、大文字小文字は 意味を持たず、サブタグは長さ 8 文字を超えてはならない （MUST NOT）ことを指定しなければならない（MUST）。 Phillips & Davis 最善現行慣行 [ページ 49]
RFC 5646 言語タグ 2009年9月 o 仕様は正準表現を指定しなければならない（MUST）。 o 有効なサブタグの仕様は、インターネット上で無償で利用可能で なければならない（MUST）。 o 仕様はパブリックドメインであるか、IETF が受け入れ可能で RFC 中 に指定されたロイヤリティフリーライセンスによって利用可能でなけ ればならない（MUST）。 o 仕様はバージョン付けされなければならず（MUST）、仕様の各 バージョンは番号付けされ、日付が付けられ、安定していなければ ならない（MUST）。 o 仕様は安定していなければならない（MUST）。すなわち、拡張 サブタグは、いったん仕様によって定義されると、撤回されたり、 意味が実質的に変更されたりしてはならない（MUST NOT）。 o 仕様は、RFC として公開された際に拡張を登録するために使用される、 この節（下記）に再掲される登録フォームを別個の節に含めなけれ ばならない（MUST）。 o 仕様の連絡先情報および URL への変更は IANA に通知されなければ ならない（MUST）。 IANA は、割り当てられた単一文字（singleton）サブタグの登録簿を 保守する。この登録簿は、Section 3.1.1 の ABNF で説明される record-jar 形式を使用しなければならない（MUST）。拡張が RFC として 公開されると、RFC で定義される保守機関はこの登録フォームを <iesg@ietf.org> に転送しなければならず（MUST）、IESG はその要求を <iana@iana.org> に転送しなければならない（MUST）。拡張の保守機関は、 内容が変更されるたびに、件名行 "LANGUAGE TAG EXTENSION UPDATE" で レコードの更新済み完全コピーを <iana@iana.org> に送信することに よって、レコードの正確性を保守しなければならない（MUST）。これらの 更新では、'Comments', 'Contact_Email', 'Mailing_List', および 'URL' フィールドのみを変更してよい（MAY）。 このレコードの保守、対応する登録簿の保守、またはこの文書のこの節 によって課されるその他の条件を満たすことに失敗した場合、他の IETF 決定と同じ規則の下で IESG [RFC2028] に不服申し立てしてよく （MAY）（[RFC2026] 参照）、また IESG により拡張を保守する権限が 撤回または再割当される結果となりうる（MAY）。 Phillips & Davis 最善現行慣行 [ページ 50]
RFC 5646 言語タグ 2009年9月 %% Identifier: Description: Comments: Added: RFC: Authority: Contact_Email: Mailing_List: URL: %% 図 6: Language Tag Extensions Registry におけるレコードの形式 'Identifier' は、拡張に割り当てられた単一文字サブタグ（singleton） を含む。拡張を定義するために提出される Internet-Draft は、使用する 文字または数字を指定すべきである（SHOULD）が、IESG は RFC を承認 するときに割当を変更してよい（MAY）。 'Description' は、拡張の名称および説明を含む。 'Comments' は OPTIONAL フィールドであり、拡張のより広い説明を含んで よい（MAY）。 '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 手続きに関連 する通常のレビューおよび不服申し立て手続きの対象となる。 拡張の著者は、多くの処理器（well-formed な処理器の大部分を含む） が、拡張サブタグの順序に内在する特別な関係 Phillips & Davis 最善現行慣行 [ページ 51]
RFC 5646 言語タグ 2009年9月 または意味を認識しないことに強く注意を促される。拡張の著者は、 照合、または拡張が使用される一般的なプロトコルにときどき存在する 長さ制限を妨げるサブタグ関係または正準化機構を避けるべきである （SHOULD）。特に、アプリケーションは、照合を行う際、または限られた 長さに収める際にサブタグを切り詰めてよい（MAY）。そのため、最も 重要な情報を最も重要な（最も左側の）サブタグに置き、仕様が切り 詰められたサブタグを適切に扱うことが RECOMMENDED である。 言語タグが特定の既知のプロトコルで使用される場合、その言語タグは そのプロトコルでサポートされていない拡張を含まないことが RECOMMENDED である。さらに、一部のプロトコルは、言語タグを保存また は転送するために使用される文字列の長さに上限を課してよい（MAY） ことに注意されたい。 3.8. 言語サブタグ登録簿の更新 この文書の採用後、IANA Language Subtag Registry は、言語タグ中で 有効なサブタグの完全な集合を含むよう更新される必要があった。 [RFC5645] は、この更新を作成するために使用された手続きを説明する。 この文書が採用された時点で [RFC4646] で定義された規則の下で 進行中の登録は、この文書に含まれる規則の下で完了されなければ ならない（MUST）。 3.9. サブタグ登録簿の適用可能性 Language Subtag Registry は、この文書で説明される規則に従って 言語タグを構築するために使用されるデータ要素の出典である。言語 タグは、テキストだけでなく、ビデオまたは音声などのほとんどの メディア形式を含む、さまざまな内容の言語的属性を示すために設計 されている。また、さまざまなプロトコルおよび API における言語 およびロケール交渉の基礎も形成する。 したがって、この登録簿は、何らかの形の言語識別を必要とする多くの アプリケーションに適用可能であるが、次の制限がある。 o 言語選択ユーザーインターフェースを作成する際の唯一のデータ源 となるよう設計されていない。たとえば、登録簿はサブタグ説明や サブタグから構成されるタグの翻訳を含まない。登録簿に基づく ローカライズ済みデータの出典は一般に利用可能であり、特に [CLDR] がある。また、登録簿はどのサブタグの組み合わせが特に 有用または関連性があるかを示さない。 Phillips & Davis 最善現行慣行 [ページ 52]
RFC 5646 言語タグ 2009年9月 o 異なる言語間の関係を示す情報を提供しない。たとえば、言語タグを 階層的、地域的、またはその他の組織モデルで選択するためにユーザー インターフェースで使用される可能性のある情報である。 o 言語を構成するものの概念は正確ではないため、異なる言語タグ間の 潜在的な重なりについての情報を提供しない。同じ所与の内容片に 対して、複数の異なる言語タグが合理的な選択肢となる可能性がある。 o 言語交渉を行うときの適切なフォールバック選択に関する情報を含ま ない。優れたフォールバック言語は、指定された言語と言語学的に 関連がない場合がある。ある言語が別の言語のフォールバック言語と してよく使用されるという事実は、通常、地理、歴史、または文化など の外部要因の結果であり、これらの要因がすべての場合に当てはまる とは限らない。たとえば、ブルトン語（フランス北西部で使用される ケルト語）を使用するほとんどの人は、ブルトン語が利用できない 場合、おそらくフランス語（ロマンス語）で提供されることを好む だろう。 4. 言語タグの形成と処理 この節では、タグ構文とともに登録簿中の情報を使用して、言語タグを 選択、形成、および処理する方法を扱う。 4.1. 言語タグの選択 言語タグを形成する際の指導原則は、「内容に賢くタグ付けする」こと である。同じ内容に対して複数の可能なタグの間で選択がある場合がある。 どのタグを使用するかの選択は、問題の内容およびアプリケーションに 依存し、タグを選択するときに一定の判断が必要となることがある。 同じ言語を表すために同じ言語タグが一貫して使用されるとき、相互運用性 は最もよく達成される。アプリケーションに、この文書の規則を適用不可能 にする要件がある場合、そのアプリケーションは相互運用性を損なう危険を 負う。利用者が言語タグ選択のために独自の規則を定義しないことが強く RECOMMENDED である。 この文書を規範的に参照するが、この節で示される規則とは異なる規則を 適用する標準、プロトコル、およびアプリケーションは、言語タグ選択が ここで示される指針とどのように異なるかを指定しなければならない（MUST）。 一貫した後方互換性を確保するため、この文書には、言語タグを構成する サブタグを定義するために使用される標準における潜在的な不安定性を 考慮するいくつかの規定が含まれる。 Phillips & Davis 最善現行慣行 [ページ 53]
RFC 5646 言語タグ 2009年9月 これらの規定は、有効な言語タグが無効になることはなく、また将来 言語タグの範囲が狭くなることもない（範囲が広くなることはある） ことを意味する。所与のアプリケーションまたは内容項目にとって 最も適切な言語タグは時間とともに発展することがあるが、いったん 適用されたタグ自体が無効になったり、その意味が完全に変わったり することはない。 サブタグは、タグに有用な識別情報を追加する場合にのみ使用すべき である（SHOULD）。余分なサブタグは、言語タグの意味、理解、および 処理を妨げる。特に、利用者および実装は、登録簿中の 'Prefix' および 'Suppress-Script' フィールド（Section 3.1 で定義）に従うべきで ある（SHOULD）。これらのフィールドは、特定の追加サブタグを言語タグ で使用すべき場合、または避けるべき場合についての指針を提供する。 言語タグを形成するために使用するサブタグの選択は、次の指針に 従うべきである（SHOULD）。 1. 可能な限り正確なタグを使用するが、正当化される以上に具体的に してはならない。アプリケーションで内容を区別するうえで重要で ないサブタグの使用は避ける。 * たとえば、ドイツ語で書かれたメールにタグ付けするには 'de' で十分な場合がある一方、"de-CH-1996" はそのような作業には おそらく不必要に正確である。 * 一部のサブタグ列は、一般利用者が期待する言語を表さない 場合があることに注意されたい。たとえば、スイスドイツ語 （Schweizerdeutsch）は "gsw-CH" で表され、"de-CH" ではない。 後者のタグは、スイス（'CH'）で使用されるドイツ語（'de'）、 すなわち Swiss High German（Schweizer Hochdeutsch）を表す。 どちらも実在する言語であり、両者を区別することがアプリケーション にとって重要となる場合がある。 2. 用字がタグに何らかの識別情報を追加しない限り、用字サブタグを 使用して言語タグを形成すべきではない（SHOULD NOT）。用字 サブタグは [RFC4646] で初めて正式に定義された。その使用は、 [RFC1766] または [RFC3066]（この文書により廃止）の実装における 照合およびサブタグ識別に影響する可能性がある。これらの サブタグは主言語サブタグと地域サブタグの間に現れるためで ある。一部のアプリケーションは、所与の文脈で使用が一貫して いる限り、言語タグに用字サブタグを使用することで利益を得る ことができる。用字サブタグは、書かれていない内容（音声録音 など）には決して適切ではない。登録簿の主言語または拡張言語 レコード中の 'Suppress-Script' フィールドは、ほとんどの アプリケーションにとって識別情報を追加しない用字サブタグを 示す。このフィールドは、利用者が特定の主言語サブタグとともに Phillips & Davis 最善現行慣行 [ページ 54]
RFC 5646 言語タグ 2009年9月 用字サブタグを含めるべきでない（SHOULD NOT）場合を定義する。 たとえば、実装が Basic Filtering [RFC4647]（元々は Section 14.4 of [RFC2616] で説明）を使用して内容を選択し、 利用者が言語範囲 "en-US" を要求した場合、"en-Latn-US" と ラベル付けされた内容はその要求に一致せず、したがって選択され ない。そのため、用字サブタグが慣習的に使用される場合と、 使用すべきでない場合を知ることが重要である。 例: * サブタグ 'Latn' は、主言語 'en' とともに使用すべきではない。 ほぼすべての英語文書はラテン文字で書かれ、それは識別情報を 追加しないためである。しかし、文書が英語で書かれ、ラテン文字 と点字（'Brai'）などの別の用字を混在させている場合、スタイル シートの適用など、内容選択を支援するために両方の用字を示す ことを選択するのが適切な場合がある。 * 書かれていない内容（人間の発話の録音など）にラベル付けする 場合、その言語が慣習的に複数の用字で書かれる場合であっても、 用字サブタグは使用すべきではない。したがって、映画の字幕は タグ "uz-Arab"（ウズベク語、アラビア文字）を使用してよいが、 同じ言語の音声トラックは単に "uz" とタグ付けされる。 （内容が書かれていない場合、サブタグ 'Zxxx' が「書かれて いない文書のためのコード」を表すため、タグ "uz-Zxxx" も 使用できる。） 3. タグまたはサブタグが登録簿エントリに 'Preferred-Value' フィールドを持つ場合、そのフィールドの値は、その優先値が現れる タグまたはサブタグより優先して、言語タグを形成するために使用 すべきである（SHOULD）。 * たとえば、Lojban には祖父化タグ "art-lojban" よりも 'jbo' を使用する。 4. 言語集合のためのサブタグよりも、個別言語のためのサブタグまたは サブタグ列を優先して使用する。"language collection" とは、共通の 祖先から派生した、同じ地理的地域で話される、またはその他の形で 関連する言語のグループである。特定の言語集合には [ISO639-5] によってコードが割り当てられている（また、これらの [ISO639-5] コードの一部は [ISO639-2] でも集合として定義されている）。 これらのコードは、主言語サブタグとして登録簿に含まれる。登録簿 中の言語集合のサブタグは、値 'collection' を持つ 'Scope' フィールドを持つ。言語集合のサブタグは、 Phillips & Davis 最善現行慣行 [ページ 55]
RFC 5646 言語タグ 2009年9月 'mul' や 'und'（下記参照）のような、より具体性の低い代替より 常に好まれ、より具体的な言語情報が利用できない場合、言語集合 を表すサブタグを使用してよい（MAY）。しかし、ほとんどの利用者 および実装は、集合とその個別言語の間に関係があることを知らない。 さらに、集合中の個別言語間の関係は十分に定義されていない。 特に、通常それらの言語は相互理解可能ではない。サブタグが異なる ため、集合への要求は通常、その集合のサブタグでタグ付けされた 項目だけを生成し、集合に含まれる個別言語のサブタグでタグ付け された項目は生成しない。 * たとえば、集合は包含的に解釈されるため、サブタグ 'gem' （ゲルマン諸語）は、"en"（英語）、"de"（ドイツ語）、または "gsw"（スイスドイツ語、アレマン語）でより適切にタグ付け される内容に使用できるが、使用すべきではない（SHOULD NOT）。 'gem' はこれら（およびその他）の言語をすべて集めたものだが、 ほとんどの実装は 'gem' を個別言語に一致させない。したがって、 このサブタグの使用は望ましい結果をもたらさない。 5. [ISO639-2] は、言語タグを選択するときに追加の注意を要する いくつかのコードをサブタグ登録簿に含めて定義している。これらの 事例の大半では、言語タグの省略が許される場合、これらのコードを 使用するより省略する方が望ましい。追加情報がアプリケーションに 何らかの価値を伝える場合を除き、言語タグはこれらのサブタグを 接頭辞として組み込むべきではない（SHOULD NOT）。 * 'mul'（Multiple）主言語サブタグは、複数言語の内容を識別する。 このサブタグは、代わりに各内容要素の言語一覧または個別タグを 使用できる場合には使用すべきではない（SHOULD NOT）。たとえば、 'Content-Language' ヘッダ [RFC3282] は、単一の言語タグだけで なく、言語の一覧を使用できるようにしている。 * 'und'（Undetermined）主言語サブタグは、言語が判定されて いない言語的内容を識別する。このサブタグは、言語タグが要求 され、かつ言語情報が利用できない、または判定できない場合を 除いて使用すべきではない（SHOULD NOT）。言語タグを省略する こと（許される場合）が望ましい。'und' サブタグは、言語タグの 提供を要求するプロトコル、または主言語サブタグが要求される 場合（"und-Latn" など）に有用な場合がある。'und' サブタグは、 特定の状況で言語タグを照合するときにも有用な場合がある （MAY）。 Phillips & Davis 最善現行慣行 [ページ 56]
RFC 5646 言語タグ 2009年9月 * 'zxx'（Non-Linguistic, Not Applicable）主言語サブタグは、 言語分類が不適切または適用不能である内容を識別する。例として、 器楽または電子音楽、非言語音から構成される録音、ナレーション、 対話、印刷された題名、または字幕を持たない視聴覚資料、機械語 または文字コードから構成される機械可読データファイル、あるいは プログラムソースコードなどがあり得る。 * 'mis'（Uncoded）主言語サブタグは、言語は知られているが、現在 対応するサブタグを持たない内容を識別する。このサブタグは使用 すべきではない（SHOULD NOT）。将来の他のコード追加により、その 適用が無効になる可能性があるため、本質的に不安定であり、した がって BCP 47 の安定性目標と相容れない。常に他のサブタグを 使用する方が望ましい。すなわち 'und'、または（事前合意の下で） 私用サブタグである。 6. 変種サブタグは控えめに、かつ正しい順序で使用する。ほとんどの 変種サブタグは、登録簿に一つ以上の 'Prefix' フィールドを持ち、 それらが適切に使用できるサブタグの一覧を表す。変種は、これら の 'Prefix' フィールドの一つに現れるサブタグとともにのみ使用 すべきである（SHOULD）。変種がその 'Prefix' フィールドの一つに 第二の変種を列挙している場合、両方が現れる任意の言語タグでは、 第一の変種は第二の変種の直後に現れるべきである（SHOULD）。 汎用変種（'Prefix' フィールドをまったく持たないもの）は、他の 任意の変種サブタグの後に現れるべきである（SHOULD）。残りの 変種は、最も重要なサブタグを先に置くことによって順序付ける。 どのサブタグもより重要でない、または関係を判定できない場合は、 サブタグをアルファベット順に並べる。変種は非常に特殊化されて いるため、多くの変種を一緒に使用すると、通常、追加の精度で得られる 利益を上回るほどタグを狭くしてしまう。サブタグを別の順序に置く ことは、相互運用性およびタグ全体の解釈を妨げる。 例: * タグ "en-scotland-fonipa"（英語、スコットランド方言、IPA 音声転写）は、'scotland' が "en" の 'Prefix' を持つ一方、 'fonipa' は 'Prefix' フィールドを持たないため、正しく順序 付けられている。 * タグ "sl-IT-rozaj-biske-1994" は正しく順序付けられている。 'rozaj' は唯一の 'Prefix' として "sl" を列挙し、'biske' は 唯一の 'Prefix' として "sl-rozaj" を列挙する。サブタグ '1994' には複数の接頭辞があり、 Phillips & Davis 最善現行慣行 [ページ 57]
RFC 5646 言語タグ 2009年9月 その中には "sl-rozaj" も含まれる。しかし、その 'Prefix' フィールドの一つが "sl-rozaj-biske" であるため、これは 'rozaj' と 'biske' の両方の後に続く。 7. 祖父化タグ "i-default"（Default Language）は、元々 [RFC1766] に従って [RFC2277] の要求を満たすために登録された。これは特定の 言語を示すためには使用されず、むしろ利用者の言語設定を確立 できない場合に使用される状態または内容を識別するためのもので ある。既定言語内容がその特定タグでラベル付けされることを要求 するアプリケーションまたはプロトコルにおいて、既定内容にラベル 付けする手段としての場合を除き、使用すべきではない（SHOULD NOT）。 また、既定言語内容が返されている場合を識別するために、アプリケーション またはプロトコルによって使用してよい（MAY）。 4.1.1. 包含言語のタグ付け 登録簿中の一部の主言語レコードは、各「包含言語」からそのマクロ言語 への写像を含む 'Macrolanguage' フィールド（Section 3.1.10）を持つ。 'Macrolanguage' 写像は、包含言語とそのマクロ言語との関係が何で あるかを定義せず、同じマクロ言語に包含される言語同士がどのように 関連するかも定義しない。同じマクロ言語に包含される二つの異なる 言語が、たとえばフランス語とスペイン語より大きく異なる場合もある。 中国語（'zh'）やアラビア語（'ar'）など、少数の特定マクロ言語は 異なる扱いを受ける。Section 4.1.2 を参照されたい。 より具体的な包含言語サブタグを使用して言語タグを形成すべきである （SHOULD）が、マクロ言語の主言語サブタグまたは包含言語のサブタグの いずれを使用してもよい（MAY）。これは、たとえば Plains Cree に 'cr'（Cree）ではなく 'crk' をタグ付けする、ということを意味する。 各マクロ言語サブタグの範囲は、定義上、そのすべての包含言語を含む。 包含言語間の関係はさまざまであるため、利用者は、マクロ言語 サブタグが特定の包含言語を意味すると仮定することも、任意の包含 言語の組が相互理解可能またはその他の形で交換可能であると仮定する こともできない。 アプリケーションは、照合または言語交渉を改善するためにマクロ言語 情報を使用してよい（MAY）。たとえば、'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 各包含言語のサブタグは、主言語サブタグとして使用すべきである （SHOULD）。たとえば、官話中国語の文書は、"zh"（中国語）よりも "cmn"（官話中国語のサブタグ）でタグ付けされるべきである。 o 互換性が望まれる、または必要である場合、包含サブタグを拡張言語 サブタグとして使用してよい（MAY）。たとえば、官話中国語の文書は、 "cmn" または "zh" の代わりに "zh-cmn" とタグ付けできる。 o より具体的な包含言語サブタグの代わりに、マクロ言語または接頭辞 付けサブタグを使用してタグを形成してもよい（MAY）。すなわち、 "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" は、米国への参照なしに、特に 'American Sign Language' を表すために登録された。これは今でも有効 だが、非推奨である。American Sign Language の文書は "ase" または "sgn-ase" のいずれかでラベル付けできる（'ase' サブタグは 'American Sign Language' と呼ばれる言語のためのものである）。 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> と書くことができる。 その場合、ドイツ語話者の利用者は、そのマークされた節の意味を 調べるために仏独辞書へアクセスできる。利用者が音声合成インターフェース を通じてその文書を聞いている場合、この形式は、合成器に対して、 不適切なドイツ語規則を適用する代わりに、そのテキスト範囲へフランス語の text-to-speech 発音規則を適切に適用するよう信号を送るために使用できる。 Phillips & Davis 最善現行慣行 [ページ 61]
RFC 5646 言語タグ 2009年9月 o 対象読者を識別できるマークアップ言語および文書形式では、言語タグ はその文書に適した対象読者を示すことができる。たとえば、前の 箇条書きで説明した同じ HTML 文書は、HTTP ヘッダ "Content-Language: de" を持ち、そのファイルの意図された読者が ドイツ語であることを示してもよい（その中に三語が現れ、フランス語 であると識別されている場合であっても）。 o システムおよび API では、言語タグはロケール識別子のほとんどの 実装の基礎を形成する。たとえば、Unicode の CLDR（Common Locale Data Repository）（UTS #35 [UTS35] 参照）プロジェクトを 参照されたい。 言語タグは、類似したサブタグ列を含むとき関連している。たとえば、 言語タグ B が言語タグ A を接頭辞として含む場合、B は通常 A より 「狭い」または「より具体的」である。したがって、"zh-Hant-TW" は "zh-Hant" より具体的である。 この関係はすべての場合に保証されるものではない。具体的には、同じ サブタグ列で始まる言語が相互理解可能であることは保証されない （NOT）が、そうである場合もある。たとえば、タグ "az" は "az-Latn"（ラテン文字を用いて書かれたアゼルバイジャン語）および "az-Cyrl"（キリル文字を用いて書かれたアゼルバイジャン語）の両方と 接頭辞を共有する。一方の用字に堪能な人が、もう一方を読めない場合が ある。たとえ言語的内容（たとえば、両方のテキストが朗読された場合に 聞こえるもの）が同一であってもである。"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. 限られたバッファサイズでの作業 一部のアプリケーションおよびプロトコルは、固定バッファサイズを割り 当てるか、その他の方法で言語タグの長さを制限せざるを得ない。適合 実装または仕様は、指定された長さを超える言語タグの保存をサポート することを拒否してよい（MAY）。そのような制限は明確に文書化すべき であり（SHOULD）、その文書化には、より長いタグに何が起こるか（たと えば、エラー値が生成されるか、言語タグが切り詰められるか）を含める べきである（SHOULD）。その限界が何であるかを示さずに、任意の限界で タグを切り詰めることを許すプロトコルは、タグの意味を実質的な方法で 変更することにより害を生じさせる可能性がある。 実際には、ほとんどの言語タグは少数のサブタグを超えて必要とせず、 合理的なサイズのバッファ制限に近づくことはない。Section 4.1 を 参照されたい。 一部の仕様またはプロトコルはタグ長に制限を持つが、固定長の制限は 持たない。たとえば、[RFC2231] には明示的な長さ制限がない。言語タグに 利用可能な長さは、他のヘッダ構成要素（charset の名前など）の長さと、 [RFC2047] の 76 文字制限との組み合わせによって制約される。したがって、 その「限界」は 50 文字以上であるかもしれないが、潜在的にはかなり 小さいこともあり得る。 バッファ制限を割り当てる際の考慮事項は次のとおりである。 実装は、タグの意味を意図的に変更している場合、または保存もしくは 転送のためにプロトコルで指定された限られたバッファサイズにタグが 収まらない場合を除き、言語タグを切り詰めるべきではない（SHOULD NOT）。 切り詰めはタグの意味を変更するため、実装はタグが切り詰められる とき利用者に警告すべきである（SHOULD）。 空間制約はあるが固定制限を持たないプロトコルまたは仕様の実装は、 切り詰めよりも、可能な限り長いタグを使用すべきである（SHOULD）。 言語タグのために限られたバッファサイズを指定するプロトコルまたは 仕様は、少なくとも 35 文字の言語タグを許容しなければならない （MUST）。[RFC4646] は 'extlang' 生成規則の三つの要素すべてを 含めていたため、最小フィールドサイズとして 42 文字を推奨していた ことに注意されたい。これらのうち二つは現在恒久的に予約されて いるため、最大長 8 文字の登録済み主言語サブタグは、現在では最長の language-extlang 組み合わせより長い。拡張または私用サブタグを 一般的に使用するプロトコルまたは仕様は、より長い「最小バッファ」 サイズを予約または推奨したい場合がある。 Phillips & Davis 最善現行慣行 [ページ 64]
RFC 5646 言語タグ 2009年9月 次の図は、35 文字の推奨値がどのように導かれたかを示す。 language = 8 ; 許可される最長の登録値 ; primary+extlang より長い ; これは 7 文字を要する script = 5 ; 抑止されない場合: Section 4.1 参照 region = 4 ; UN M.49 数値地域コード ; ISO 3166-1 コードは 3 文字を要する variant1 = 9 ; 接頭辞として 'language' が必要 variant2 = 9 ; 非常にまれ。なぜなら ; 接頭辞として 'language-variant1' が必要 total = 35 文字 図 7: タグ長制限の導出 4.4.2. 言語タグの切り詰め 言語タグの切り詰めはタグの意味を変えるため、避けるべきである （SHOULD）。しかし、限られたバッファサイズのため、言語タグの切り 詰めが必要となることがある。そのような切り詰めでは、サブタグを途中 で切断すること、または無効なタグ（たとえば "-" 文字で終わるもの） を形成することを許してはならない（MUST NOT）。 これは、タグを切り詰めるアプリケーションまたはプロトコルは、所与の バッファに対してタグが十分短くなるまで、言語タグの右側からサブタグ とその前の "-" を段階的に削除することによってそうしなければならない （MUST）ことを意味する。結果のタグが単一文字サブタグで終わる場合、 そのサブタグとその前の "-" も削除されなければならない（MUST）。 例: 切り詰めるタグ: 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. 言語タグの正準化 特定の言語タグは多くの処理で使用されうるため、言語タグは常に正準 形式で作成または生成されるべきである（SHOULD）。 言語タグは、Sections 2.1 および 2.2 の規則に従って well-formed であり、IANA 登録簿のデータ（Section 3.1 参照）を使用して、次の 各手順を順に適用することで正準化されている場合、'canonical form' である。 1. 拡張列は、singleton サブタグにより、大文字小文字を区別しない ASCII 順に並べられる。 * たとえば、サブタグ列 '-a-babble' は '-b-warble' より前に 置かれる。 2. 冗長タグまたは祖父化タグは、存在する場合、その 'Preferred- Value' に置き換えられる。 * 祖父化タグおよび冗長タグの 'Preferred-Value' の field-body は "extended language range" [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 は "extended language range" であり、通常は主言語サブタグへ写像する。 たとえば、サブタグ列 "zh-hak"（中国語、客家語）はサブタグ 'hak'（客家語）に置き換えられる。 * 非 extlang サブタグの大半は、国名または呼称が変更された Region サブタグ、または ISO 639-1 への事務的修正である。 Phillips & Davis 最善現行慣行 [ページ 66]
RFC 5646 言語タグ 2009年9月 正準形式は 'extlang' サブタグを含まない。extlang サブタグを維持または 復元する代替の 'extlang form' が存在する。この形式は、照合または選択 において 'Prefix' サブタグの存在が有益と見なされる環境で有用な場合が ある（Section 4.1.2 参照）。 言語タグは、Sections 2.1 および 2.2 の規則に従って well-formed であり、IANA 登録簿のデータを使用して、次の二つの手順を順に適用 することで処理されている場合、'extlang form' である。 1. 言語タグはまず、上述のように正準形式へ変換される。 2. 言語タグが、extlang サブタグでもある主言語サブタグで始まる場合、 その言語タグの前に extlang の 'Prefix' が付加される。 * たとえば、"hak-CN"（客家語、中国）は主言語サブタグ 'hak' を 持ち、これはさらに 'Prefix' 'zh'（中国語）を持つ 'extlang' レコードを持つ。extlang form は "zh-hak-CN"（中国語、客家語、 中国）である。 * Step 2（接頭辞の前置）は、Step 1（正準化）によって削除された サブタグを復元できることに注意されたい。 例: 言語タグ "en-a-aaa-b-ccc-bbb-x-xyz" は正準形式である。一方、 "en-b-ccc-bbb-a-aaa-X-xyz" は well-formed であり、潜在的に有効 （拡張 'a' および 'b' はこの文書の公開時点では定義されていない）だが、 正準形式ではない（拡張がアルファベット順でない）。 例: タグ "en-BU"（ビルマで使用される英語）は有効性を維持するが、 言語タグ "en-BU" は正準形式ではない。なぜなら 'BU' サブタグは 'MM'（ミャンマー）への正準写像を持つためである。 言語タグの正準化は、サブタグを処理または比較するときの大文字または 小文字の使用について何も意味しない（Section 2.1 で説明される とおり）。すべての比較は、大文字小文字を区別しない方法で実行され なければならない（MUST）。 言語タグの正準化を実行するとき、処理器は、登録簿で使用される大文字 小文字（Section 2.1.1 参照）に従って、サブタグの大文字小文字を 正規化してよい（MAY）（すなわち、この処理は OPTIONAL である）。 Phillips & Davis 最善現行慣行 [ページ 67]
RFC 5646 言語タグ 2009年9月 一つのタグ内に複数の変種が現れる場合、処理器は、よりよい照合動作 またはより一貫した提示を得るために、変種を並べ替えてよい（MAY）。 変種の並べ替えは、Section 4.1 における変種順序の推奨に従うべき である（SHOULD）。 フィールド 'Deprecated' が、付随する 'Preferred-Value' フィールド なしに登録簿レコードに現れる場合、そのタグまたはサブタグは置換なしで 非推奨である。これらの値は、言語タグに現れる場合は正準である。しかし、 これらの値を含むタグは、利用者によって選択されるべきではなく （SHOULD NOT）、実装によって生成されるべきではない（SHOULD NOT）。 拡張は、その拡張中の各種サブタグ間に存在する任意の関係を定義しなければ ならず（MUST）、したがって拡張のサブタグに対する代替の正準化方式を定義 してよい（MAY）。拡張は、拡張のサブタグの順序がどのように解釈されるかを 定義してよい（MAY）。たとえば、ある拡張は、そのサブタグが ASCII 順に 配置されているとき正準順序であると定義できる。すなわち、 "en-a-ccc-bbb-aaa" ではなく "en-a-aaa-bbb-ccc" である。別の拡張は、 サブタグの順序がその意味に影響すると定義するかもしれない（そのため "en-b-ccc-bbb-aaa" は "en-b-aaa-bbb-ccc" とは異なる値を持つ）。 しかし、拡張仕様は、Section 3.7 で説明される典型的な処理に対して 寛容であるよう設計されるべきである（SHOULD）。 4.6. 私用サブタグに関する考慮事項 私用サブタグは、他のすべてのサブタグと同様に、ABNF の形式および 内容上の制約に適合しなければならない（MUST）。私用サブタグは、それを 使用する、またはそれを用いる言語タグを交換する意図を持つ当事者間の 私的な合意の外では意味を持たない。同じサブタグを、別個の私的な合意の 下で異なる意味で使用してよい（MAY）。代替手段が存在する場合には使用 すべきではなく（SHOULD NOT）、一般使用を意図した内容またはプロトコル で使用すべきではない（SHOULD NOT）。 私用サブタグは、事前の取り決めなしには情報交換にまったく役立たない。 私用タグおよびそのような言語タグ内で使用されるサブタグの値および 意味は、この文書によって定義されない。 'x' singleton によって導入される私用列は、私用合意の外にある利用者 または実装にとって完全に不透明である。したがって、singleton サブタグ 'x' によって導入される私用サブタグ列に加え、Language Subtag Registry は、基礎となる標準によって割り当てられた私用コードから派生した私用の 言語、用字、および地域サブタグを提供する。これらのサブタグは言語タグを 形成するために有効である。これらは、言語タグ固有の構造との結び付きに よってより多くの情報を伝えるため、'x' singleton 私用サブタグ列よりも RECOMMENDED である。 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 はまた、 登録簿の変更および更新を通知するため、新しいメーリングリスト （下記 Section 5.1 で説明）を作成することも要求される。 5.1. 言語サブタグ登録簿 IANA は、関連文書 [RFC5645] で提供された指示および内容を使用して 登録簿を更新した。更新されたレコード集合を選択するための基準および 手続きはその文書で説明されている。更新されたレコード集合は IANA へ 影響を与えない。なぜなら、それを作成する作業は外部で実行されるため である。 Language Subtag Registry に関する将来の作業には、次の活動が含まれる。 o レコード全体を挿入または置換すること。これらのレコードは、 Section 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" 形式でなければならない（SHALL）。 日付は、その版の登録簿が IANA によって最初に公開された日付でなければ ならない（SHALL）。登録簿の版は、一日に最大一つしか公開されてはなら ない（SHALL）。IANA への各レコード挿入または変更要求にも 'File-Date' レコードが含まれ、要求中のレコードの受理日を示す。 更新された登録簿ファイルは UTF-8 文字符号化を使用しなければならず （MUST）、IANA は登録簿ファイルの適切な符号化を確認しなければならない （MUST）。非 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 は新しいレコードを時折この登録簿に 挿入するよう要求してよい（MAY）。これらの要求は、Section 3.7 で 説明される正確な形式で、挿入するレコードを含まなければならない （MUST）。さらに、特定の拡張の保守機関から、レコード中の連絡先情報 または URL を更新するための要求が時折あるかもしれない（MAY）。これら の要求は、完全な更新済みレコードを含まなければならない（MUST）。IANA は、提供された情報の検証について責任を負わず、それが適切に書式化 されていることだけに責任を負う。IANA は、要求が登録簿中に存在する レコードに記名された保守機関から来ていることを確認するため、合理的な 措置を取るべきである（SHOULD）。 6. セキュリティに関する考慮事項 内容交渉で使用される言語タグは、インターネット上で交換される他の 任意の情報と同様に、送信者の国籍を推測するために使用され、したがって 監視の潜在的標的を識別するために使用される可能性があるため、懸念の 原因となる場合がある。 これは、送信されたものは受信側に見え、場合によっては第三者にも見える という一般的問題の特殊な事例である。そのような懸念が存在しうる場合が あることを認識しておくことは有用である。 脅威の正確な大きさの評価、および可能な対策は、各アプリケーション プロトコルに委ねられる（セキュリティ上の脅威と防御に関する最善現行 慣行の指針については BCP 72 [RFC3552] を参照）。 特定の情報項目に関連付けられた言語タグは、その内容が潜在的な同形異義 文字を含むかどうかを判断するうえで、まったく何の意味も持たない。ある テキストが一つの言語である、または特定の用字サブタグを使用していると タグ付けされているという事実は、それがその言語タグに関連付けられた、 または指定された用字以外の用字の文字を含まないという保証をまったく 提供しない。 変種、私用、および拡張サブタグの数に制限はなく、その結果としてタグの 可能な長さにも制限がないため、実装はバッファオーバーフロー攻撃に備える 必要がある。バッファオーバーフローへの防御の結果として発生しうる言語 タグの切り詰めの詳細については、Section 4.4 を参照されたい。 Phillips & Davis 最善現行慣行 [ページ 71]
RFC 5646 言語タグ 2009年9月 サービス拒否攻撃を防ぐため、アプリケーションは Language Subtag Registry または Language Tag Extensions Registry のいずれかが常に アクセス可能であることに依存すべきではない（SHOULD NOT）。さらに、 拡張の有効なサブタグの仕様（Section 3.7 参照）はインターネット上で 利用可能でなければならない（MUST）が、実装はそれらの出典が常に アクセス可能であることに機械的に依存すべきではない（SHOULD NOT）。 この文書で指定される登録簿は、完全な登録簿内容への頻繁な、または リアルタイムのアクセスや取得には適していない。ほとんどのアプリケーション は登録簿データをまったく必要としない。他のアプリケーションについても、 特定の登録簿日付時点で言語タグを検証または正準化できれば十分である。 登録簿内容はたまにしか変更されないためである。変更は <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 を変更した。不規則タグは現在列挙されて いる。well-formed な祖父化タグは現在 'langtag' 生成規則によって 説明され、その結果 'grandfathered' 生成規則は削除された。また、 両方の型の祖父化タグの説明を Section 2.2.8 に追加した。 o 「collections」に関する段落を Section 4.1 に追加した。 o Section 3.1 における 'Tag' フィールドの大文字化規則を変更した。 o Section 3.1 を小節に分割した。 o 登録手続きを通じて 'Suppress-Script' フィールドを追加、変更、 または削除できるよう Section 3.5 を修正した。これは RFC 4646 からの正誤表であった。 o 地域コード 'CS'（旧セルビア・モンテネグロ）を使用していた例を、 代わりに 'RS'（セルビア）を使用するよう修正した。 Phillips & Davis 最善現行慣行 [ページ 73]
RFC 5646 言語タグ 2009年9月 o 重複（倒置重複を含む）を防ぐため、レコードの 'Description' フィールドを作成および保守する規則を修正した。 o この節から、RFC 4646 が作成された理由に関する長い説明を削除し、 これにより XML Schema への参照も削除された。 o 言語タグが大文字小文字を区別しないという事実をより強調するため、 Section 2.1 の本文を修正した。 o Section 2.1 の例 "fr-Latn-CA" を "sr-Latn-RS" および "az-Arab-IR" に置き換えた。"fr-Latn-CA" は 'fr' に対する 'Latn' の 'Suppress-Script' を尊重していないためである。 o Section 2.2.9 で、singleton の反復チェックを optional にする よう well-formedness の要件を変更した（これは validity チェックでは 要求される）。 o 祖父化チェックに言及する Section 2.2.9 の本文を変更し、その一覧が 現在 ABNF に含まれていることを述べた。 o Section 3.2 の本文を修正および追加した。職務記述を最初に置いた。 Language Subtag Reviewer が、リスト司会を含む各種の重要でない作業を 委任できることを明確にする注記を追加した。最後に、任命手続きを 明確にし、審査者の決定および遂行が不服申し立て可能であることを 明確にする追加本文を追加した。 o ietf-languages@iana.org リストが IESG の任命する者によって運営 されることを明確にする本文を Section 3.5 に追加した。 o 'language' レコード中の最初の Description が ISO 639-3 における その言語の対応する Reference Name に一致することを明確にする本文を Section 3.1.5 に追加した。 o 特定のタグに関連する適合性のクラスを定義するよう Section 2.2.9 を修正した（以前は 'well-formed' および 'valid' は実装を指していた）。 RFC 4646 で提供された ABNF から 'extlang' が削除されたことに関する 注記を追加し、この古い定義を使用した well-formedness を許容した。 RFC 3066 の well-formedness への参照も追加した。 o この文書の将来の版が登録簿形式に新しいフィールド型を追加する 可能性があることを述べ、実装に未知のフィールドを無視することを 推奨する本文を Section 3.1.2 の末尾に追加した。 Phillips & Davis 最善現行慣行 [ページ 74]
RFC 5646 言語タグ 2009年9月 o レコードに 'Suppress-Script' フィールドがないことの意味についての 本文を Section 3.1.9 に追加した。 o 綴り誤りおよび組版上の誤りの修正を許可する本文を Section 3.1.5 に追加した。 o 'Prefix' フィールドの衝突（循環接頭辞参照など）を禁止する本文を Section 3.1.8 に追加した。 o 2 週間の期間後に Subtag Reviewer が自身の決定（または延長）を 発表することを要求するよう Section 3.5 の本文を修正した。 また、任意の決定または決定しないことが不服申し立て可能であることを 明確にした。 o （これまで逸話的であった）タグ選択の指導原則を含め、非書記用途に おける用字サブタグの不使用を明確にするよう Section 4.1 の本文を 修正した。 o タグ内で同じ変種を複数回使用すること（すなわち "de-1901-1901"） を禁止した。以前はこれは推奨（"SHOULD"）に過ぎなかった。 o Section 4.4.1 の図から不適切な [RFC2119] 言語を削除した。 o Section 4.5 で "zh-guoyu" の非推奨化の例を "zh-hakka"->"hak" に 置き換え、この文書がその変更を引き起こしたことを述べた。 o Section 4.1 の "mul"/"und" を扱う節を置き換え、サブタグ 'zxx' と 'mis'、およびタグ "i-default" を含めた。RFC 2277 への規範的 参照を追加した。 o 登録要求の任意の変更は、IANA への提出前に <ietf-languages@iana.org> リストへ送信されなければならないことを 明確にする本文を Section 3.5 に追加した。 o record-jar 形式の ABNF を、LWSP 生成規則の使用から、[RFC5234] の obs-FWS に類似した折り返し空白生成規則を使用するよう変更した。 これは、フィールド内の意図しない空行を実質的に防止する。 o Sections 3.3, 3.5, および 5.1 の本文を明確化および改訂し、 Language Subtag Reviewer が完全な登録フォームを IANA へ送信し、 IANA がフォームからレコードを抽出し、フォームも登録簿とは別に 保管されなければならないことを明確にした。 Phillips & Davis 最善現行慣行 [ページ 75]
RFC 5646 言語タグ 2009年9月 o 登録簿が更新されるたびに IANA が ietf-languages-announcements リストへ通知を送信することを要求する本文を Section 5 に追加した。 o 登録簿が文字符号化として UTF-8 を使用するよう変更した。これには、 登録手続きにおける IANA および Language Subtag Reviewer への追加 指示も伴う。 o 'UK' 以外の「例外的に予約された」ISO 3166-1 コードが登録簿に 含まれるよう、Section 2.2.4 の規則を修正した。特に、これにより コード 'EU'（European Union）を言語タグの形成に使用でき、また （より一般的には）地域コードのために登録簿を使用するアプリケーション がこのサブタグを参照できる。 o 不要な規範的 [RFC2119] 言語を削除するため、IANA に関する考慮事項 の節（Section 5）を修正した。 9. 参考文献 9.1. 規範的参考文献 [ISO15924] International Organization for Standardization, "ISO 15924:2004. Information and documentation -- Codes for the representation of names of scripts", January 2004. [ISO3166-1] International Organization for Standardization, "ISO 3166-1:2006. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", November 2006. [ISO639-1] International Organization for Standardization, "ISO 639-1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code", July 2002. [ISO639-2] International Organization for Standardization, "ISO 639-2:1998. Codes for the representation of names of languages -- Part 2: Alpha-3 code", October 1998. [ISO639-3] International Organization for Standardization, "ISO 639-3:2007. Codes for the representation of names of languages - Part 3: Alpha-3 code for comprehensive coverage of languages", February 2007. Phillips & Davis 最善現行慣行 [ページ 76]
RFC 5646 言語タグ 2009年9月 [ISO639-5] International Organization for Standardization, "ISO 639-5:2008. Codes for the representation of names of languages -- Part 5: Alpha-3 code for language families and groups", May 2008. [ISO646] International Organization for Standardization, "ISO/IEC 646:1991, Information technology -- ISO 7-bit coded character set for information interchange.", 1991. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", BCP 47, RFC 4647, September 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [SpecialCasing] The Unicode Consoritum, "Unicode Character Database, Special Casing Properties", March 2008, <http:// unicode.org/Public/UNIDATA/SpecialCasing.txt>. [UAX14] Freitag, A., "Unicode Standard Annex #14: Line Breaking Properties", August 2006, <http://www.unicode.org/reports/tr14/>. [UN_M.49] Statistics Division, United Nations, "Standard Country or Area Codes for Statistical Use", Revision 4 (United Nations publication, Sales No. 98.XVII.9, June 1999. 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)", January 2007. 9.2. 参考情報文献 [CLDR] "The Common Locale Data Repository Project", <http://cldr.unicode.org>. [RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997. [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, June 1999. [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", RFC 3066, January 2001. [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. Phillips & Davis 最善現行慣行 [ページ 78]
RFC 5646 言語タグ 2009年9月 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4645] Ewell, D., "Initial Language Subtag Registry", RFC 4645, September 2006. [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006. [RFC5645] Ewell, D., Ed., "Update to the Language Subtag Registry", September 2009. [UTS35] Davis, M., "Unicode Technical Standard #35: Locale Data Markup Language (LDML)", December 2007, <http://www.unicode.org/reports/tr35/>. [iso639.prin] ISO 639 Joint Advisory Committee, "ISO 639 Joint Advisory Committee: Working principles for ISO 639 maintenance", March 2000, <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月 Appendix A. 言語タグの例（参考情報） 単純な言語サブタグ: de（ドイツ語） fr（フランス語） ja（日本語） i-enochian（祖父化タグの例） 言語サブタグと用字サブタグ: zh-Hant（繁体字中国語で書かれた中国語） zh-Hans（簡体字中国語で書かれた中国語） sr-Cyrl（キリル文字で書かれたセルビア語） sr-Latn（ラテン文字で書かれたセルビア語） 拡張言語サブタグと、それに対応する主言語サブタグ: zh-cmn-Hans-CN（中国語、官話、簡体字、中国で使用） cmn-Hans-CN（官話中国語、簡体字、中国で使用） zh-yue-HK（中国語、広東語、香港 SAR で使用） yue-HK（広東語中国語、香港 SAR で使用） 言語-用字-地域: zh-Hans-CN（中国本土で使用される簡体字で書かれた中国語） sr-Latn-RS（セルビアで使用されるラテン文字で書かれたセルビア語） Phillips & Davis 最善現行慣行 [ページ 80]
RFC 5646 言語タグ 2009年9月 言語-変種: sl-rozaj（スロベニア語のレジア方言） sl-rozaj-biske（スロベニア語のレジア方言の San Giorgio 方言） sl-nedis（スロベニア語の Nadiza 方言） 言語-地域-変種: de-CH-1901（1901 年変種［正書法］を使用する、スイスで使用される ドイツ語） sl-IT-nedis（イタリアで使用されるスロベニア語、Nadiza 方言） 言語-用字-地域-変種: hy-Latn-IT-arevela（ラテン文字で書かれ、イタリアで使用される東 アルメニア語） 言語-地域: de-DE（ドイツのためのドイツ語） en-US（米国で使用される英語） es-419（UN 地域コードを用いたラテンアメリカおよびカリブ地域に 適したスペイン語） 私用サブタグ: 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 によって定義されなければならない（MUST））: en-US-u-islamcal zh-CN-a-myext-x-private en-a-myext-b-another 無効なタグの例: de-419-DE（二つの地域タグ） a-DE（主位置で単一文字サブタグを使用。なお、"i-" で始まる有効な 祖父化タグが少数存在する） ar-a-aaa-b-bbb-a-ccc（同じ単一文字接頭辞を持つ二つの拡張） Appendix B. 登録フォームの例 LANGUAGE SUBTAG REGISTRATION FORM 1. Name of requester: Han Steenwijk 2. E-mail address of requester: han.steenwijk @ unipd.it 3. Record Requested: Type: variant Subtag: biske Description: The San Giorgio dialect of Resian Description: The Bila dialect of Resian Prefix: sl-rozaj Comments: The dialect of San Giorgio/Bila is one of the four major local dialects of Resian 4. Intended meaning of the subtag: San Giorgio/Bila で話される Resian の地域変種 5. Reference to published description of the language (book or article): -- Jan I.N. Baudouin de Courtenay - Opyt fonetiki rez'janskich govorov, Varsava - Peterburg: Vende - Kozancikov, 1875. Phillips & Davis 最善現行慣行 [ページ 82]
RFC 5646 言語タグ 2009年9月 LANGUAGE SUBTAG REGISTRATION FORM 1. Name of requester: Jaska Zedlik 2. E-mail address of requester: jz53 @ zedlik.com 3. Record Requested: Type: variant Subtag: tarask Description: Belarusian in Taraskievica orthography Prefix: be Comments: The subtag represents Branislau Taraskievic's Belarusian orthography as published in "Bielaruski klasycny pravapis" by Juras Buslakou, Vincuk Viacorka, Zmicier Sanko, and Zmicier Sauka (Vilnia-Miensk 2005). 4. Intended meaning of the subtag: このサブタグは、Juras Buslakou、Vincuk Viacorka、Zmicier Sanko、 および Zmicier Sauka による "Bielaruski klasycny pravapis" （Vilnia-Miensk 2005）で公開されたベラルーシ語正書法を表すことを 意図している。 5. Reference to published description of the language (book or article): 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. Any other relevant information: Taraskievica 正書法のベラルーシ語は、特にベラルーシ語インターネット 分野で広く使用されるようになったが、これに加えて、このベラルーシ語 正書法を使用して印刷される書籍や新聞もある。 Appendix 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]