Internet Engineering Task Force (IETF) M. Davis
Request for Comments: 6067 Google
Category: Informational A. Phillips
ISSN: 2070-1721 Lab126
Y. Umaoka
IBM
December 2010
Extension U
Abstract
抽象
This document specifies an Extension to BCP 47 that provides subtags that specify language and/or locale-based behavior or refinements to language tags, according to work done by the Unicode Consortium.
このドキュメントは、Unicodeコンソーシアムが行った作業に応じて、言語タグに言語および/またはロケールに基づく行動や改良を指定サブタグを提供BCP 47への拡張を指定します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6067.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6067で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 2
2. BCP 47 Required Information . . . . . . . . . . . . . . . . . . 2
2.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Canonicalization . . . . . . . . . . . . . . . . . . . 5
2.2. Registration Form . . . . . . . . . . . . . . . . . . . . . 6
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 7
[BCP47] permits the definition and registration of language tag extensions "that contain a language component and are compatible with applications that understand language tags". This document defines an extension for identifying Unicode locale-based variations using language tags. The "singleton" identifier for this extension is 'u'.
[BCP47]「言語の成分を含有し、言語タグを理解するアプリケーションとの互換性のある」言語タグ拡張の定義と登録が可能になります。この文書は、言語タグを使用してユニコードロケールベースの変化を識別するための拡張を定義します。この拡張のための「シングルトン」識別子は、「U」です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Language tags, as defined by [BCP47], are useful for identifying the language of content. They are also used as locale identifiers (or can be mapped to locales) in many operating environments and APIs. However, many locale identifiers also require additional "tailorings" or options for specific values within a language, culture, region, or other variation. This extension provides a mechanism for using these additional tailorings within language tags for general interchange.
言語タグは、[BCP47]によって定義されるように、コンテンツの言語を同定するために有用です。彼らはまた、ロケール識別子として使用されている（またはロケールにマッピングすることができる）は、多くの動作環境およびAPIに。しかし、多くのロケール識別子はまた、追加の「特性の手直し」や言語、文化、地域内の特定の値、または他のバリエーションのためのオプションが必要です。この拡張は、一般的な交換のための言語タグの中にこれらの追加特性の手直しを使用するためのメカニズムを提供します。
The Unicode Consortium defines a standardized, structured set of locale data and identifiers for locale data in the "Common Locale Data Repository" or "CLDR". The maintaining authority for the extension defined by this document is the Unicode Consortium:
ユニコードコンソーシアムは、「共通ロケールデータリポジトリ」または「CLDR」のロケールデータのロケールデータと識別子の標準化され、構造化されたセットを定義します。この文書で定義された拡張のための維持の権限は、Unicodeコンソーシアムです。
+---------------+---------------------------------------------------+
| Item | Value |
+---------------+---------------------------------------------------+
| Name | Unicode Consortium |
| Contact Email | cldr-contact@unicode.org |
| Discussion | cldr-users@unicode.org |
| List Email | |
| URL Location | cldr.unicode.org |
| Specification | Unicode Technical Standard #35 Unicode Locale |
| | Data Markup Language (LDML), |
| | http://unicode.org/reports/tr35/ |
| Section | Section 3 Unicode Language and Locale Identifiers |
+---------------+---------------------------------------------------+
The specification of extension subtags is provided by Section 3, Key Type Definitions of Unicode Technical Standard #35: Unicode Locale Data Markup Language [UTS35]. As required by BCP 47, subtags follow the language tag ABNF and other rules for the formation of language tags and subtags, are restricted to the ASCII letters and digits, are not case sensitive, and do not exceed eight characters in length. Note that any "well-formed" language tag (see RFC 5646, Section 2.2.9 [BCP47]) is also a well-formed locale identifier.
ユニコードロケール・データ・マークアップ言語[UTS35]：拡張サブタグの仕様は、第3、ユニコード技術標準のキータイプ定義＃35によって提供されます。 BCP 47で要求されているように、言語タグABNFと言語タグとサブタグの形成のための他の規則に従ってサブタグ、大文字と小文字を区別しません、ASCII文字と数字に制限されており、長さが8つの文字を超えてはなりません。任意の「整形式」言語タグ（RFC 5646、セクション2.2.9 [BCP47]を参照のこと）もまた整形ロケール識別子であることに留意されたいです。
LDML [UTS35] specifies a canonical representation. LDML is available over the Internet and at no cost, and is available via a royalty-free license at http://unicode.org/copyright.html. LDML is versioned, and each version of LDML is numbered, dated, and stable. Extension subtags, once defined by LDML, are never retracted and never change in meaning in a substantial way.
LDMLは、[UTS35]標準的な表現を指定します。 LDMLは、インターネット上でかつ無償で利用可能で、http://unicode.org/copyright.htmlでロイヤリティフリーのライセンスを経由して提供されています。 LDMLがバージョン管理され、そしてLDMLの各バージョンは、番号付け、かつ安定です。一度LDMLによって定義された拡張サブタグは、引っ込めたことがないとかなりの方法で、意味に変更されることはありません。
The structure of the Unicode locale extension is determined by the Unicode CLDR Technical Committee, in accordance with the policies and procedures in http://www.unicode.org/consortium/tc-procedures.html, and subject to the Unicode Consortium Policies on http://www.unicode.org/policies/policies.html.
ユニコードロケール拡張の構造をhttp://www.unicode.org/consortium/tc-procedures.htmlにおける方針と手順に従い、ユニコードCLDR技術委員会によって決定され、上のユニコードコンソーシアムポリシーの対象とされていますhttp://www.unicode.org/policies/policies.html。
Changes that can be made by successive versions of LDML [UTS35] by the Unicode Consortium without requiring a new RFC include: the allocation of new attributes, keywords, and types; clarifications or non-material changes to an existing attribute, keyword, or type; and compatible extensions to the overall syntactic structure of attributes, keywords, and types. A new RFC would be required for material changes to an existing attribute, keyword, or type, or an incompatible change to the overall syntactic structure of attributes, keywords, and types; however, such a change would be contrary to the policies of the Unicode Consortium, and thus is not anticipated.
新しいRFCを必要とせずに、ユニコードコンソーシアムによってLDML [UTS35]の連続したバージョンで行うことができる変更は、新しい属性、キーワード、およびタイプの割り当てと、既存の属性、キーワード、またはタイプへの明確化や非物質の変化;そして、属性、キーワード、および種類の全体的な構文構造に互換性の拡張機能。新しいRFCは、既存の属性、キーワード、またはタイプへの材料の変更、または属性、キーワード、および種類の全体的な構文構造に互換性のない変更のために必要とされるであろう。しかし、このような変更は、Unicodeコンソーシアムの方針に反するとなり、ひいては予想されていません。
The subtags available for use in the 'u' extension consist of a set of attributes, keys, and types. Attributes, keys, types, and their respective meanings are defined in Section 3 (Unicode Language and Locale Identifiers) of [UTS35]. The following is a summary of that definition:
「U」の拡張子で使用するために利用可能なサブタグは、属性、キー、およびタイプのセットで構成されています。属性、キー、タイプ、およびそれぞれの意味は[UTS35]のセクション3（Unicodeの言語およびロケール識別子）で定義されています。以下は、その定義をまとめたものです：
o An 'attribute' is a subtag with a length of three to eight characters following the singleton and preceding any 'keyword' sequences. No attributes were defined at the time of this document's publication.
O「属性は」シングルトンと任意の「キーワード」配列の前に、次の3〜8文字の長さとサブタグです。何の属性は、このドキュメントの発行時点では定義されませんでした。
o A 'keyword' is a sequence of subtags consisting of a 'key' subtag, followed by zero or more 'type' subtags (so a 'key' might appear alone and not be accompanied by a 'type' subtag). A 'key' MUST NOT appear more than once in a language tag's extension string. The order of the 'type' subtags within a 'keyword' is sometimes significant to their interpretation.
「キーワード」Oゼロ以上の「タイプ」サブタグ（そう 'キーは「タイプ」サブタグを伴うことだけでは表示されない可能性があります）、続いて、「鍵」サブタグからなるサブタグの配列です。 「キーは」言語タグの拡張文字列内で複数回出現することはできません。 「キーワード」内の「タイプ」サブタグの順序は、その解釈に時々重要です。
A. A 'key' is a subtag with a length of exactly two characters. Each 'key' is followed by zero or more 'type' subtags.
A. A「キー」を正確に2文字の長さとサブタグです。各「キー」は、ゼロ個以上の「タイプ」のサブタグが続いています。
B. A 'type' is a subtag with a length of three to eight characters following a 'key'. 'Type' subtags are specific to a particular 'key' and the order of the 'type' subtags MAY be significant to the interpretation of the 'keyword'.
B. A「type」は「キー」は次の3〜8文字の長さとサブタグです。 「タイプ」のサブタグは、特定の「キー」と「タイプ」の順に固有のサブタグは、「キーワード」の解釈に重要であり得ます。
For example, the language tag "de-DE-u-attr-co-phonebk" consists of:
例えば、言語タグ "脱DE-U-ATTR-CO-phonebkは" から成ります。
o The base language tag "de-DE" (German as used in Germany), exactly as defined by [BCP47] using subtags from the IANA Language Subtag Registry.
[BCP47] IANA言語サブタグレジストリからサブタグを使用して定義されたとおりにベース言語タグ（ドイツで使用されるドイツ語）「脱DE」、O。
o The singleton 'u', identifying this extension.
シングルトンO「U」は、この拡張機能を識別する。
o The attribute 'attr', which is an example for illustration (no attributes were defined at the time this document was published).
説明のための例である属性「ATTR」、O（何属性は、この文書が公開された時に定義されませんでした）。
o The keyword 'co-phonebk', consisting to the key 'co' (Collation) and the type 'phonebk' (Phonebook collation order).
キー「コ」（照合）とタイプ「phonebk」（電話帳照合順）になるキーワード「共phonebk」は、O。
Only the first occurrence of an attribute or key conveys meaning in a language tag. When interpreting tags containing the Unicode locale extension, duplicate attributes or keywords are ignored in the following way: ignore any attribute that has already appeared in the tag and ignore any keyword whose key has already occurred in the tag.
言語タグに意味属性またはキー伝えるだけ最初に出現しました。 Unicodeのロケールの拡張子を含むタグを解釈すると、重複した属性またはキーワードは次のように無視されます。すでにタグに登場している任意の属性を無視し、そのキーすでにタグで発生したすべてのキーワードを無視します。
Successive versions of [UTS35] could define additional attributes, keys, and types. Once defined, attributes, keys, and types will never be removed.
[UTS35]の連続したバージョンでは、追加の属性、キー、およびタイプを定義することができます。定義されたら、属性キー、およびタイプは削除されません。
Beginning with CLDR version 1.7.2, machine-readable files are available listing the valid attributes, keys, and types for each successive version of [UTS35]. These releases are listed on http://cldr.unicode.org/index/downloads. Each release has an associated data directory of the form "http://unicode.org/Public/cldr/<version>", where "<version>" is replaced by the release number. For example, for version 1.7.2, the "core.zip" file is located at http://unicode.org/Public/cldr/1.7.2/core.zip. Inside the "core.zip" file, the path "common/bcp47" contains the data files defining the valid attributes, keys, and types. The most recent version is always identified by the version "latest" and can be accessed by the URL in Section 2.2.
CLDRバージョン1.7.2以降では、機械可読ファイルは、[UTS35]の各連続バージョンの有効な属性、キー、およびタイプをリストできます。これらのリリースはhttp://cldr.unicode.org/index/downloadsに上場されています。各リリースは、フォームの関連データディレクトリが「http://unicode.org/Public/cldr/ <バージョン>」、ここで「<バージョン>」がリリース番号に置き換えられています。例えば、バージョン1.7.2のために、「core.zip」ファイルはhttp://unicode.org/Public/cldr/1.7.2/core.zipに位置しています。 「core.zip」ファイル内では、パス「共通/ BCP47は、」有効な属性、キー、およびタイプを定義するデータファイルが含まれています。最新のバージョンは常にバージョン「最新」で識別され、2.2節でURLでアクセスすることができます。
To get the version information in XML when working with the data files, the XML parser must be validating. When the 'core.zip' file is unzipped, the 'dtd' directory will be at the same level as the 'bcp47' directory; this is required for correct validation. For each release after CLDR 1.8, types introduced in that release are also marked in the data files by the XML attribute "since", such as in the following example: <type name="adp" since="1.9"/>
データファイルを扱う際にXMLにバージョン情報を取得するには、XMLパーサは、検証する必要があります。 「core.zip」ファイルを解凍した場合、「DTD」ディレクトリには、「BCP47」ディレクトリと同じレベルになります。これは、正しい検証に必要とされます。 CLDR 1.8以降の各リリースでは、このリリースで導入されたタイプはまた、次の例のように、「以来の」XML属性によるデータファイルにマークされている。<タイプ名=「ADP」以来=「1.9」/>
The data is also currently maintained in a source code repository, with each release tagged, for viewing directly without unzipping. For example, see:
データはまた、現在解凍せずに直接観察するため、タグ付けされたリリースごとに、ソースコードリポジトリに維持されます。たとえば、以下を参照してください。
o http://unicode.org/repos/cldr/tags/release-1-7-2/common/bcp47/
お ｈっｔｐ：／／うにこで。おｒｇ／れぽｓ／ｃｌｄｒ／たｇｓ／れぇあせー１ー７ー２／こっもん／ｂｃｐ４７／
o http://unicode.org/repos/cldr/tags/release-1-8/common/bcp47/
お ｈっｔｐ：／／うにこで。おｒｇ／れぽｓ／ｃｌｄｒ／たｇｓ／れぇあせー１ー８／こっもん／ｂｃｐ４７／
Some data in the CLDR data files might require reference to LDML [UTS35]. For specific information, see Appendix Q in that document. For example, LDML reserves the type 'codepoints' to define specific code point ranges in Unicode for specific purposes.
CLDRデータファイルの一部のデータは、[UTS35] LDMLへの参照が必要になることがあります。具体的な情報については、その文書の付録Qを参照してください。例えば、LDMLは、特定の目的のためにユニコードに特定のコードポイント範囲を定義するタイプ「コードポイント」を留保します。
As required by [BCP47], the use of uppercase or lowercase letters is not significant in the subtags used in this extension. The canonical form for all subtags in the extension is lowercase. The canonical order of attributes is in [US-ASCII] order (that is, numbers before letters, with letters sorted as lowercase US-ASCII code points). The canonical order of keywords is in [US-ASCII] order by key. The order
[BCP47]によって要求されるように、大文字または小文字の使用は、この拡張に使用サブタグに重要ではありません。拡張子のすべてのサブタグのための正規の形式は小文字です。属性の標準的な順序は、[US-ASCII]程度である（すなわち、数小文字のUS-ASCIIコードポイントとしてソート文字と文字の前）。キーワードの標準的な順序は、キーによる[US-ASCII]の順序です。オーダー
of subtags within a keyword is significant; the meaning of this extension is altered if those subtags are rearranged. Thus, the canonical form of the extension never reorders the subtags within a keyword.
キーワード内のサブタグで重要です。これらのサブタグが再配置されている場合は、この拡張機能の意味が変更されています。このように、延長の正規の形式は、キーワード内のサブタグを並べ替えることはありません。
Per RFC 5646, Section 3.7 [BCP47]:
RFC 5646あたり、3.7節[BCP47]：
%% Identifier: u Description: Unicode Locale Comments: Subtags for the identification of language and cultural variations. Used to set behavior in locale APIs. Data is located in the "common/bcp47" directory inside the referenced URL. Unicode Technical Standard #35 (LDML) provides additional reference material defining the keys and values. For more details please see <http://cldr.unicode.org/index/bcp47-extension>. Added: 2010-09-02 RFC: RFC 6067 Authority: Unicode Consortium Contact_Email: cldr-contact@unicode.org Mailing_List: cldr-users@unicode.org URL: http://www.unicode.org/Public/cldr/latest/core.zip %%
%%識別子：U説明：言語および文化的変化の同定のためのサブタグ：ユニコードロケールコメント。ロケールのAPIで動作を設定するために使用します。データが参照したURL内の「共通/ BCP47」ディレクトリにあります。ユニコード技術標準＃35（LDML）はキーと値を定義する追加の参考資料を提供します。詳細については、<http://cldr.unicode.org/index/bcp47-extension>を参照してください。追加：2010-09-02 RFC：RFC 6067機関：ユニコードコンソーシアムCONTACT_EMAIL：cldr-contact@unicode.org Mailing_List：cldr-users@unicode.org URL：http://www.unicode.org/Public/cldr/latest /core.zip %%
Thanks to John Emmons and the rest of the Unicode CLDR Technical Committee for their work in developing the BCP 47 subtags for LDML.
LDMLのためのBCP 47サブタグを開発する上で自分の仕事のためにジョン・エモンズとUnicode CLDR技術委員会の残りに感謝します。
Thanks also to Doug Ewell, for his many suggestions for improvements to this document.
また、ダグイーウェルに、彼の多くの提案については、このドキュメントに改善してくれてありがとう。
According to this document, IANA has inserted the record in Section 2.2 into the Language Extensions Registry, according to Section 3.7 (Extensions and the Extensions Registry) of [BCP47], "Tags for Identifying Languages". Per Section 5.2 of [BCP47], there might be occasional (rare) requests by the Unicode Consortium (the "Authority" listed in the record) for maintenance of this record. Changes that can be submitted to IANA without the publication of a new RFC are limited to modification of the Comments, Contact_Email, Mailing_List, and URL fields. Any such requested changes MUST use the domain 'unicode.org' in any new addresses or URIs, MUST explicitly cite this document (so that IANA can reference these requirements), and MUST originate from the 'unicode.org' domain. The domain or authority can only be changed via a new RFC.
この文献によれば、IANAは、「言語を識別するためのタグ」、[BCP47]のセクション3.7（拡張機能と拡張機能レジストリ）によれば、言語拡張レジストリにセクション2.2にレコードを挿入しました。 5.2節[BCP47]のあたりに、このレコードのメンテナンスのためのUnicodeコンソーシアム（レコードに記載されている「当局」）によって、時折（まれ）の要求があるかもしれません。新しいRFCの公表なしでIANAに提出することができます変更はコメント、CONTACT_EMAIL、Mailing_List、およびURLフィールドの変更に制限されています。そのような任意の要求された変更は、新しいアドレスまたはURIのドメイン「unicode.org」を使用しなければならない、明示的に（IANAがこれらの要件を参照できるように）、この文書を引用しなければならない、と「unicode.org」ドメインから発信する必要があります。ドメインまたは権限が唯一の新しいRFCを介して変更することができます。
The security considerations for this extension are the same as those for [BCP47]. See RFC 5646, Section 6, Security Considerations [BCP47].
この拡張のためのセキュリティの考慮事項は、[BCP47]と同じです。 [BCP47] RFC 5646、セクション6、セキュリティについての考慮事項を参照してください。
[BCP47] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[BCP47]フィリップス、A.編。そして、M.デイヴィス、エド。、 "言語を識別するためのタグ"、BCP 47、RFC 5646、2009年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[US-ASCII] International Organization for Standardization, "ISO/IEC 646:1991, Information technology -- ISO 7-bit coded character set for information interchange.", 1991.
[US-ASCII]国際標準化機構、 "ISO / IEC 646：1991、情報技術 - 情報交換のためのISO 7ビット符号化文字集合。"、1991年。
[UTS35] Davis, M., "Unicode Technical Standard #35: Locale Data Markup Language (LDML)", December 2007, <http://www.unicode.org/reports/tr35/>.
[UTS35]デイビス、M.、 "Unicodeの技術標準＃35：ロケール・データマークアップ言語（LDML）"、2007年12月、<http://www.unicode.org/reports/tr35/>。
Section 3: http://unicode.org/reports/
tr35/#Unicode_Language_and_Locale_Identifiers
Appendix Q: http://unicode.org/reports/ tr35/#Locale_Extension_Key_and_Type_Data
付録Q：http://unicode.org/reports/ TR35 /＃Locale_Extension_Key_and_Type_Data
[ldml-registry] "Registry for Common Locale Data Repository tag elements", September 2009.
2009年9月[LDML-レジストリ]「共通ロケールデータリポジトリタグ要素のレジストリ」。
Authors' Addresses
著者のアドレス
Mark Davis Google
マーク・デイビスグーグル
EMail: mark@macchiato.com
メールアドレス：mark@macchiato.com
Addison Phillips Lab126
アディソン・フィリップスLab126
EMail: addison@lab126.com
メールアドレス：addison@lab126.com
Yoshito Umaoka IBM
よしと うまおか いＢＭ
EMail: yoshito_umaoka@us.ibm.com
メールアドレス：yoshito_umaoka@us.ibm.com