| |
| |
| |
| Internet Engineering Task Force M. Davis |
| Internet-Draft Google |
| Intended status: Informational A. Phillips |
| Expires: June 7, 2012 Lab126 |
| Y. Umaoka |
| IBM |
| C. Falk |
| Infinite Automata |
| December 5, 2011 |
| |
| |
| BCP 47 Extension T - Transformed Content |
| draft-davis-t-langtag-ext-07 |
| |
| Abstract |
| |
| This document specifies an Extension to BCP 47 which provides subtags |
| for specifying the source language or script of transformed content, |
| including content that has been transliterated, transcribed, or |
| translated, or in some other way influenced by the source. It also |
| provides for additional information used for identification. |
| |
| Status of this Memo |
| |
| This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |
| |
| Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |
| |
| Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |
| |
| This Internet-Draft will expire on June 7, 2012. |
| |
| Copyright Notice |
| |
| Copyright (c) 2011 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |
| |
| This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |
| |
| |
| |
| Davis, et al. Expires June 7, 2012 [Page 1] |
| |
| Internet-Draft BCP 47 Extension T December 2011 |
| |
| |
| carefully, as they describe your rights and restrictions with respect |
| to this document. |
| |
| |
| Table of Contents |
| |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 |
| 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 |
| 2. BCP47 Required Information . . . . . . . . . . . . . . . . . . 4 |
| 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 2.2. Structure . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 2.3. Canonicalization . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.4. BCP47 Registration Form . . . . . . . . . . . . . . . . . 8 |
| 2.5. Field Definitions . . . . . . . . . . . . . . . . . . . . 8 |
| 2.6. Registration of Field Subtags . . . . . . . . . . . . . . 10 |
| 2.7. Registration of Additional Fields . . . . . . . . . . . . 10 |
| 2.8. Committee Responses to Registration Proposals . . . . . . 11 |
| 2.9. Machine-Readable Data . . . . . . . . . . . . . . . . . . 11 |
| 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 |
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 |
| 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 |
| 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Davis, et al. Expires June 7, 2012 [Page 2] |
| |
| Internet-Draft BCP 47 Extension T December 2011 |
| |
| |
| 1. Introduction |
| |
| [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 specifying the source of content that has been |
| transformed, including text that has been transliterated, |
| transcribed, or translated, or in some other way influenced by the |
| source. It may be used in queries to request content that has been |
| transformed. The "singleton" identifier for this extension is 't'. |
| |
| Language tags, as defined by [BCP47], are useful for identifying the |
| language of content. There are mechanisms for specifying variant |
| subtags for special purposes. However, these variants are |
| insufficient for specifying content that has undergone |
| transformations, including content that has been transliterated, |
| transcribed, or translated. The correct interpretation of the |
| content may depend upon knowledge of the conventions used for the |
| transformation. |
| |
| Suppose that Italian or Russian cities on a map are transcribed for |
| Japanese users. Each name needs to be transliterated into katakana |
| using rules appropriate for the specific source and target language. |
| When tagging such data, it is important to be able to indicate not |
| only the resulting content language ("ja" in this case), but also the |
| source language. |
| |
| Transforms such as transliterations may vary depending not only on |
| the basis of the source and target script, but also on the source and |
| target language. Thus the Russian <U+041F U+0443 U+0442 U+0438 |
| U+043D> (which corresponds to the Cyrillic <PE, U, TE, I, EN>) |
| transliterates into "Putin" in English but "Poutine" in French. The |
| identifier could be used to indicate a desired mechanical |
| transformation in an API, or could be used to tag data that has been |
| converted (mechanically or by hand) according to a transliteration |
| method. |
| |
| In addition, many different conventions have arisen for how to |
| transform text, even between the same languages and scripts. For |
| example, "Gaddafi" is commonly transliterated from Arabic to English |
| as any of (G/Q/K/Kh)a(d/dh/dd/dhdh/th/zz)af(i/y). Some examples of |
| standardized conventions used for transcribing or transliterating |
| text include: |
| |
| a. United Nations Group of Experts on Geographical Names (UNGEGN) |
| |
| b. US Library of Congress (LOC) |
| |
| |
| |
| |
| Davis, et al. Expires June 7, 2012 [Page 3] |
| |
| Internet-Draft BCP 47 Extension T December 2011 |
| |
| |
| c. US Board on Geographic Names (BGN) |
| |
| d. Korean Ministry of Culture, Sports and Tourism (MCST) |
| |
| e. International Organization for Standardization (ISO) |
| |
| The usage of this extension is not limited to formal transformations, |
| and may include other instances where the content is in some other |
| way influenced by the source. For example, this extension could be |
| used to designate a request for a speech recognizer that is tailored |
| specifically for 2nd-language speakers who are 1st-language speakers |
| of a particular language (e.g. a recognizer for "English spoken with |
| a Chinese accent"). |
| |
| 1.1. Requirements Language |
| |
| 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. |
| |
| |
| 2. BCP47 Required Information |
| |
| 2.1. Overview |
| |
| Identification of transformed content can be done using the 't' |
| extension defined in this document. This extension is formed by the |
| 't' singleton followed by a sequence of subtags that would form a |
| language tag as defined by [BCP47]. This allows for the source |
| language or script to be specified to the degree of precision |
| required. There are restrictions on the sequence of subtags. They |
| MUST form a regular, valid, canonical language tag, and MUST neither |
| include extensions nor private use sequences introduced by the |
| singleton 'x'. Where only the script is relevant (such as |
| identifying a script-script transliteration) then 'und' is used for |
| the primary language subtag. |
| |
| For example: |
| |
| +---------------------+---------------------------------------------+ |
| | Language Tag | Description | |
| +---------------------+---------------------------------------------+ |
| | ja-t-it | The content is Japanese, transformed from | |
| | | Italian. | |
| | ja-Kana-t-it | The content is Japanese Katakana, | |
| | | transformed from Italian. | |
| |
| |
| |
| |
| |
| Davis, et al. Expires June 7, 2012 [Page 4] |
| |
| Internet-Draft BCP 47 Extension T December 2011 |
| |
| |
| | und-Latn-t-und-cyrl | The content is in the Latin script, | |
| | | transformed from the Cyrillic script. | |
| +---------------------+---------------------------------------------+ |
| |
| Note that the sequence of subtags governed by 't' cannot contain a |
| singleton (a single-character subtag), because that would start a new |
| extension. For example, the tag "ja-t-i-ami" does not indicate that |
| the source is in "i-ami", because "i-ami" is not a regular language |
| tag in [BCP47]. That tag would express an empty 't' extension |
| followed by an 'i' extension. |
| |
| The 't' extension is not intended for use in structured data that |
| already provides separate source and target language identifiers. |
| For example, this is the case in localization interchange formats |
| such as XLIFF. In such cases, it would be inappropriate to use "ja- |
| t-it" for the target language tag because the source language tag |
| "it" would already be present in the data. Instead one would use the |
| language tag "ja". |
| |
| As noted earlier, it is sometimes necessary to indicate additional |
| information about a transformation. This additional information is |
| optionally supplied after the source in a series of one or more |
| fields, where each field consists of a field separator subtag |
| followed by one or more non-separator subtags. Each field separator |
| subtag consists of a single letter followed by a single digit. |
| |
| A transformation mechanism is an optional field that indicates the |
| specification used for the transformation, such as "UNGEGN" for the |
| the United Nations Group of Experts on Geographical Names |
| transliterations and transcriptions. It uses the 'm0' field |
| separator followed by certain subtags. |
| |
| For example: |
| |
| +------------------------------------+------------------------------+ |
| | Language Tag | Description | |
| +------------------------------------+------------------------------+ |
| | und-Cyrl-t-und-latn-m0-ungegn-2007 | the content is in Cyrillic, | |
| | | transformed from Latn, | |
| | | according to a UNGEGN | |
| | | specification dated 2007. | |
| +------------------------------------+------------------------------+ |
| |
| The field separator subtags such as 'm0' were chosen because they are |
| short, visually distinctive, and cannot occur in a language subtag |
| (outside of an extension and after 'x'), thus eliminating the |
| potential for collision or confusion with the source language tag. |
| |
| |
| |
| |
| Davis, et al. Expires June 7, 2012 [Page 5] |
| |
| Internet-Draft BCP 47 Extension T December 2011 |
| |
| |
| The field subtags are defined by Section 3 [1] of Unicode Technical |
| Standard #35: Unicode Locale Data Markup Language [UTS35] (LDML), the |
| main specification for the Unicode Common Locale Data Repository |
| (CLDR) project. 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. |
| |
| EDITORIAL NOTE: This new facility has been accepted by the Unicode |
| CLDR committee for incorporation into the next versions of CLDR and |
| LDML, parallel with the structure of the 'u' extension [RFC6067], for |
| which it is already the maintaining authority. The data and |
| specification will be available by the time this internet draft has |
| been approved. |
| |
| The LDML specification 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 or substantially changed in |
| meaning. |
| |
| The maintaining authority for the 't' extension is the Unicode |
| Consortium: |
| |
| +---------------+---------------------------------------------------+ |
| | 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 | |
| +---------------+---------------------------------------------------+ |
| |
| 2.2. Structure |
| |
| The subtags in the 't' extension are of the following form: |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Davis, et al. Expires June 7, 2012 [Page 6] |
| |
| Internet-Draft BCP 47 Extension T December 2011 |
| |
| |
| t-ext= "t" ; Extension |
| (("-" lang *("-" field)) ; Source + optional field(s) |
| / 1*("-" field)) ; Field(s) only (no source) |
| |
| lang= language ; BCP47, with restrictions |
| ["-" script] |
| ["-" region] |
| *("-" variant) |
| |
| field= sep 1*("-" 3*8alphanum) ; With restrictions |
| |
| sep= ALPHA DIGIT ; Subtag separators |
| alphanum= ALPHA / DIGIT |
| |
| where <language>, <script>, <region>, and <variant> rules are |
| specified in [BCP47], <ALPHA> and <DIGIT> rules - in [RFC5234]. |
| |
| Description and restrictions: |
| |
| a. The 't' extension MUST have at least one subtag. |
| |
| b. The 't' extension normally starts with a source language tag, |
| which MUST be a regular, canonical language tag as specified by |
| [BCP47]. Tags described by the 'irregular' production in BCP 47 |
| MUST NOT be used to form the language tag. The source language |
| tag MAY be omitted: some field values do not require it. |
| |
| c. There is optionally a sequence of fields, where each field has a |
| separator followed by a sequence of one or more subtags. Two |
| identical field separators MUST NOT be present in the language |
| tag. |
| |
| d. The order of the fields in a 't' extension is not significant. |
| The order of subtags within a field is significant. (See |
| Section 2.3 Canonicalization.) |
| |
| e. The 't' subtag fields are defined by Section 3 [1] of Unicode |
| Technical Standard #35: Unicode Locale Data Markup Language |
| [UTS35]. |
| |
| 2.3. Canonicalization |
| |
| 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, with the fields |
| ordered by the separators, alphabetically. The order of subtags |
| within a field is significant, and MUST NOT be changed in the process |
| of canonicalizing. |
| |
| |
| |
| Davis, et al. Expires June 7, 2012 [Page 7] |
| |
| Internet-Draft BCP 47 Extension T December 2011 |
| |
| |
| 2.4. BCP47 Registration Form |
| |
| Per RFC 5646, Section 3.7 [BCP47]: |
| |
| %% |
| Identifier: t |
| Description: Specifying Transformed Content |
| Comments: Subtags for the identification of content that has been |
| transformed, including but not limited to: |
| transliteration, transcription, and translation. |
| Added: 2010-mm-dd |
| RFC: [TBD] |
| 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 |
| %% |
| |
| 2.5. Field Definitions |
| |
| Assignment of 't' field subtags 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. |
| |
| Assignments that can be made by successive versions of LDML [UTS35] |
| by the Unicode Consortium without requiring a new RFC include: |
| |
| o The allocation of new field separator subtags for use after the |
| 't' extension. |
| |
| o The allocation of subtags valid after a field separator subtag. |
| |
| o The addition of subtag aliases and descriptions. |
| |
| o The modification of subtag descriptions. |
| |
| Changes to the syntax or meaning of the 't' extension would require a |
| new RFC that obsoletes this document; such an RFC would break |
| stability, and would thus be contrary to the policies of the Unicode |
| Consortium. |
| |
| At the time this document was published, one field was specified in |
| [UTS35]: the transform mechanism. That field is summarized here: |
| |
| a. The transform mechanism consists of a sequence of subtags |
| starting with the 'm0' separator followed by one or more |
| |
| |
| |
| Davis, et al. Expires June 7, 2012 [Page 8] |
| |
| Internet-Draft BCP 47 Extension T December 2011 |
| |
| |
| mechanism subtags. Each mechanism subtag has a length of 3 to 8 |
| alphanumeric characters. The sequence as a whole provides an |
| identification of the specification for the transform, such as |
| the mechanism subtag 'ungegn' in "und-Cyrl-t-und-latn-m0-ungegn". |
| In many cases, only one mechanism subtag is necessary, but |
| multiple subtags MAY be defined in [UTS35] where necessary. |
| |
| b. Any purely numeric subtag is a representation of a date in the |
| Gregorian calendar. It MAY occur in any mechanism field, but it |
| SHOULD only be used where necessary. If it does occur: |
| |
| * it MUST occur as the final subtag in the field |
| |
| * it MUST NOT be the only subtag in the field |
| |
| * it MUST only consist of a sequence of digits of the form YYYY, |
| YYYYMM, or YYYYMMDD |
| |
| * it SHOULD be as short as possible |
| |
| Note: The format is related to that of [RFC3339], but is not the |
| same. The RFC 3339 full-date won't work because it uses hyphens. |
| The offset ("Z") is not used because the date is a publication |
| date (aka 'floating date'). For more information, see Section |
| 3.3, Floating Time in [W3C-TimeZones]. |
| |
| c. Examples: |
| |
| * 20110623 represents June 23rd, 2011. |
| |
| * There are 3 dated versions of the UNGEGN transliteration |
| specification for Hebrew to Latin. They can be represented by |
| the following language tags: |
| |
| + und-Hebr-t-und-Latn-m0-ungegn-1972 |
| |
| + und-Hebr-t-und-Latn-m0-ungegn-1977 |
| |
| + und-Hebr-t-und-Latn-m0-ungegn-2007 |
| |
| * Suppose that the BGN transliteration specification for |
| Cyrillic to Latin had three versions, dated June 11th, 1999; |
| Dec 30th, 1999; and May 1st, 2011. In that case, the |
| corresponding first two DATE subtags would require months to |
| be distinctive (199906 and 199912), but the last subtag would |
| only require the year (2011). |
| |
| |
| |
| |
| |
| Davis, et al. Expires June 7, 2012 [Page 9] |
| |
| Internet-Draft BCP 47 Extension T December 2011 |
| |
| |
| d. Some mechanisms may use a versioning system that is not |
| distinguished by date, or not by date alone. In the latter case, |
| the version will be of a form specified by [UTS35] for that |
| mechanism. For example, if the mechanism XXX uses versions of |
| the form v21a, then a tag could look like "ja-t-it-m0-xxx-v21a". |
| If there are multiple subversions distinguished by date, then a |
| tag could look like "ja-t-it-m0-xxx-v21a-2007". |
| |
| A language tag with the 't' extension MAY be used to request a |
| specific transform of content. In such a case, the recipient SHOULD |
| return content that corresponds as closely as feasible to the |
| requested transform, including the specification of the mechanism. |
| For example, if the request is ja-t-it-m0-xxx-v21a-2007, and the |
| recipient has content corresponding to both ja-t-it-m0-xxx-v21a and |
| ja-t-it-m0-xxx-v21b-2009, then the v21a version would be preferred. |
| As is the case for language matching as discussed in [BCP47], |
| different implementations MAY have different measures of "closeness". |
| |
| 2.6. Registration of Field Subtags |
| |
| Registration of transform mechanisms is requested by filing a ticket |
| at cldr.unicode.org [2]. The proposal in the ticket MUST contain the |
| following information: |
| |
| +-------------+-----------------------------------------------------+ |
| | Item | Description | |
| +-------------+-----------------------------------------------------+ |
| | Subtag | The proposed mechanism subtag (or subtag sequence). | |
| | Description | A description of the proposed mechanism; that | |
| | | description MUST be sufficient to distinguish it | |
| | | from other mechanisms in use. | |
| | Version | If versioning for the mechanism is not done | |
| | | according to date, then a description of the | |
| | | versioning conventions used for the mechanism. | |
| +-------------+-----------------------------------------------------+ |
| |
| Proposals for clarifications of descriptions or additional aliases |
| may also be requested by filing a ticket. |
| |
| The committee MAY define a template for submissions that requests |
| more information, if it is found that such information would be |
| useful in evaluating proposals. |
| |
| 2.7. Registration of Additional Fields |
| |
| In the event that it proves necessary to add an additional field |
| (such as 'm2'), it can be requested by filing a ticket at |
| cldr.unicode.org [2]. The proposal in the ticket MUST contain a full |
| |
| |
| |
| Davis, et al. Expires June 7, 2012 [Page 10] |
| |
| Internet-Draft BCP 47 Extension T December 2011 |
| |
| |
| description of the proposed field semantics and subtag syntax, and |
| MUST be conform to the ABNF syntax for "field" presented in |
| Section 2.2. |
| |
| 2.8. Committee Responses to Registration Proposals |
| |
| The committee MUST post each proposal publicly within 2 weeks after |
| reception, to allow for comments. The committee must respond |
| publicly to each proposal within 4 weeks after reception. |
| |
| The response MAY: |
| |
| o request more information or clarification |
| |
| o accept the proposal, optionally with modifications to the subtag |
| or description |
| |
| o reject the proposal, because of significant objections raised on |
| the mailing list or due to problems with constraints in this |
| document or in [UTS35] |
| |
| Accepted tickets result in a new entry in the machine-readable CLDR |
| BCP47 data, or in the case of a clarified description, modifications |
| to the description attribute value for an existing entry. |
| |
| 2.9. Machine-Readable Data |
| |
| EDITORIAL NOTE: The following parallels the structure used for the |
| 'u' extension [RFC6067], for which the Unicode Consortium is the |
| maintaining authority. The data and specification will be available |
| by the time this internet draft has been approved. The description |
| field is in the process of being added to CLDR. |
| |
| Beginning with CLDR version 1.7.2, machine-readable files are |
| available listing the data defined for BCP47 extensions 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 [3]. The most recent |
| version is always identified by the version "latest" and can be |
| accessed by the URL in Section 2.4. |
| |
| Inside the "core.zip" file, the directory "common/bcp47" contains the |
| data files listing the valid attributes, keys, and types for each |
| successive version of [UTS35]. Each data file list the keys and |
| |
| |
| |
| Davis, et al. Expires June 7, 2012 [Page 11] |
| |
| Internet-Draft BCP 47 Extension T December 2011 |
| |
| |
| types relevant to that topic. For example, mechanism.xml contains |
| the subtags (types) for the 't' mechanisms. |
| |
| The XML structure lists the keys, such as <key extension="t" |
| name="m0" alias="collation" description="Transliteration extension |
| mechanism">, with subelements for the types, such as <type |
| name="ungegn" description="United Nations Group of Experts on |
| Geographical Names"/>. The currently defined attributes for the |
| mechanisms include: |
| |
| +-------------+-------------------------------+---------------------+ |
| | Attribute | Description | Examples | |
| +-------------+-------------------------------+---------------------+ |
| | name | The name of the mechanism, | UNGEGN, ALALC | |
| | | limited to 3-8 characters (or | | |
| | | sequences of them). | | |
| | description | A description of the name, | United Nations | |
| | | with all and only that | Group of Experts on | |
| | | information necessary to | Geographical Names; | |
| | | distinguish one name from | American Library | |
| | | others with which it might be | Association-Library | |
| | | confused. Descriptions are | of Congress | |
| | | not intended to provide | | |
| | | general background | | |
| | | information. | | |
| | since | Indicates the first version | 1.9, 2.0.1 | |
| | | of CLDR where the name | | |
| | | appears. (Required for new | | |
| | | items.) | | |
| | alias | Alternative name of the key | | |
| | | or type, not limited in | | |
| | | number of characters. | | |
| | | Aliases are intended for | | |
| | | backwards compatibility, not | | |
| | | to provide all possible | | |
| | | alternate names or | | |
| | | designations. (Optional) | | |
| +-------------+-------------------------------+---------------------+ |
| |
| The file for the transform extension is "transform.xml". The initial |
| version of that file contains the following information. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Davis, et al. Expires June 7, 2012 [Page 12] |
| |
| Internet-Draft BCP 47 Extension T December 2011 |
| |
| |
| <key extension="t" name="m0" description= |
| "Transliteration extension mechanism"/> |
| <type name="ungegn" description= |
| "United Nations Group of Experts on Geographical Names"/> |
| <type name="alaloc" description= |
| "American Library Association-Library of Congress"/> |
| <type name="bgn" description= |
| "US Board on Geographic Names"/> |
| <type name="mcst" description= |
| "Korean Ministry of Culture, Sports and Tourism"/> |
| <type name="iso" description= |
| "International Organization for Standardization"/> |
| <type name="din" description= |
| "Deutsches Institut fuer Normung"/> |
| <type name="gost" description= |
| "Euro-Asian Council for Standardization, Metrology |
| and Certification"/> |
| </key> |
| |
| 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; that 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"/> |
| |
| 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/ |
| |
| For more information, see |
| http://cldr.unicode.org/index/bcp47-extension. |
| |
| |
| 3. Acknowledgements |
| |
| Thanks to John Emmons and the rest of the Unicode CLDR Technical |
| Committee for their work in developing the BCP 47 subtags for LDML. |
| |
| |
| |
| |
| |
| |
| |
| Davis, et al. Expires June 7, 2012 [Page 13] |
| |
| Internet-Draft BCP 47 Extension T December 2011 |
| |
| |
| 4. IANA Considerations |
| |
| This document will require IANA to insert the record of Section 2.4 |
| into the Language Extensions Registry, according to Section 3.7, |
| Extensions and the Extensions Registry of "Tags for Identifying |
| Languages" in [BCP47]. 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. |
| |
| This document does not require IANA to create or maintain a new |
| registry or otherwise impact IANA. |
| |
| |
| 5. Security Considerations |
| |
| The security considerations for this extension are the same as those |
| for [BCP47]. See RFC 5646, Section 6, Security Considerations |
| [BCP47]. |
| |
| |
| 6. References |
| |
| 6.1. Normative References |
| |
| [BCP47] Davis, M., Ed. and A. Phillips, Ed., "Tags for the |
| Identification of Language (BCP47)", September 2009. |
| |
| [RFC5234] Crocker, Ed., "Augmented BNF for Syntax Specifications: |
| ABNF", 2008. |
| |
| [RFC6067] Davis, M., Ed., Phillips, A., Ed., and Y. Umaoka, Ed., |
| "BCP 47 Extension U", September 2010. |
| |
| [UTS35] Davis, M., "Unicode Technical Standard #35: Locale Data |
| Markup Language (LDML)", December 2007, |
| <http://www.unicode.org/reports/tr35/>. |
| |
| 6.2. Informative References |
| |
| [RFC3339] Klyne, Ed. and Newman, Ed., "Date and Time on the |
| Internet: Timestamps", 2002. |
| |
| |
| |
| Davis, et al. Expires June 7, 2012 [Page 14] |
| |
| Internet-Draft BCP 47 Extension T December 2011 |
| |
| |
| [W3C-TimeZones] |
| Phillips, Ed., "W3C Working Group Note: Working with Time |
| Zones", July 2011, |
| <http://www.w3.org/TR/2011/NOTE-timezone-20110705/>. |
| |
| [ldml-registry] |
| "Registry for Common Locale Data Repository tag elements", |
| September 2009. |
| |
| URIs |
| |
| [1] <http://unicode.org/reports/tr35/> |
| |
| [2] <http://cldr.unicode.org/> |
| |
| [3] <http://unicode.org/Public/cldr/1.7.2/> |
| |
| |
| Authors' Addresses |
| |
| Mark Davis |
| Google |
| |
| Email: mark@macchiato.com |
| |
| |
| Addison Phillips |
| Lab126 |
| |
| Email: addison@lab126.com |
| |
| |
| Yoshito Umaoka |
| IBM |
| |
| Email: yoshito_umaoka@us.ibm.com |
| |
| |
| Courtney Falk |
| Infinite Automata |
| |
| Email: court@infiauto.com |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Davis, et al. Expires June 7, 2012 [Page 15] |
| |
