Tags for the Identification of Languages
Extracted elements (19)
All primary tag values other than 2-letter ISO 639 codes, 'i', and 'x' are reserved to remain open toward new revisions of ISO 639. The 'i' and 'x' designations are the minimum mechanism needed to extend the tag scheme to meet future requirements.
Language tag codes are always expressible in the US-ASCII character repertoire (a-z), which is present in most character sets. The question of selecting a character set rendering based solely on a language tag is not addressed, as it is considered impossible to resolve correctly in all cases (e.g., mixed Japanese-Chinese text).
The meaning of a language tag relative to the information it annotates is defined by the standard describing the context in which it appears. For a single object it denotes languages required for complete comprehension; for aggregations it denotes languages used in components; for alternatives it is a hint that content is provided in multiple languages.
The MIME specification (RFC 1521), section 7.2, states that headers not beginning with 'Content-' are generally to be ignored in body parts; designers defining headers for use with the 'differences=' parameter should take note of this constraint.
When composing a Multipart/Alternative message with language variants, the first body part should most likely be in the language understood by most recipients, since non-MIME mail readers will display the first body part first.
All 2-letter codes in the first subtag are interpreted as ISO 3166 alpha-2 country codes denoting the area in which the language is used. Subtag codes of 3 to 8 letters may be registered with IANA by anyone who feels a need, per the rules in section 5.
All 2-letter primary tags are interpreted according to ISO 639 'Code for the representation of names of languages'. No other assignment is possible for 2-letter tags without updating this standard.
All language tags are to be treated as case insensitive. Conventions for capitalization (lowercase language codes, uppercase country codes) are recommended but must not be taken to carry meaning.
Applications should always treat language tags as a single token; the division into main tag and subtags is an administrative mechanism, not a navigation aid. There is no guaranteed mutual comprehensibility between languages whose tags share a common prefix.
Further values for the Differences parameter must be registered with IANA and must be the name of a header for which a definition exists in a published RFC.
The language tag always defines a language as spoken or written by human beings for communication of information to other human beings. Computer languages are explicitly excluded.
The language tag registration form must be sent to the ietf-types mailing list for a 2-week review period before submission to IANA. The reviewer either forwards it to IANA or rejects it based on significant objections raised on the list.
The primary tag value 'i' is reserved for IANA-defined registrations; the value 'x' is reserved for private use, and subtags of 'x' will not be registered by IANA. All other primary tag values outside 2-letter ISO 639 codes cannot be assigned except by updating this standard.
When using Multipart/Alternative body parts to convey the same content in different languages, a Content-Language header should be placed on each body part, and a summary Content-Language header should be placed on the Multipart/Alternative itself.
A new 'Differences' parameter is defined for the Multipart/Alternative content type. Its value is one or more of 'Content-Type' or 'Content-Language' (or other IANA-registered header names from published RFCs), indicating which headers a MIME reader should examine to intelligently select the best alternative for the user. If absent, Differences=Content-Type is assumed.
The Content-Language header field is defined for RFC-822-like headers (e.g., MIME body parts, Web documents). Its EBNF is: Language-Header = "Content-Language" ":" 1#Language-Tag, allowing a comma-separated list of one or more language tags with optional whitespace and parenthesized comments.
IANA administers the namespace of language tags. Any new language tag must start with an existing tag and extend it. Proposed registrations require submission of a registration form (including requester name, email, tag, English name, native name, and published language reference), a 2-week review on [email protected], and approval by the IETF Applications Area Director-appointed reviewer before forwarding to IANA. Decisions may be appealed to the IESG.
Security issues are not discussed in this memo. No security considerations are identified for the language tag mechanism itself.
A language tag is composed of a primary tag and zero or more subtags separated by hyphens: Language-Tag = Primary-tag *( "-" Subtag ), where Primary-tag and each Subtag are 1 to 8 ASCII alpha characters. Whitespace is not allowed within the tag.