draft-ietf-ltru-registry-09.txt   draft-ietf-ltru-registry-10.txt 
Network Working Group A. Phillips, Ed. Network Working Group A. Phillips, Ed.
Internet-Draft Quest Software Internet-Draft Quest Software
Expires: January 12, 2006 M. Davis, Ed. Expires: February 5, 2006 M. Davis, Ed.
IBM IBM
July 11, 2005 August 04, 2005
Tags for Identifying Languages Tags for Identifying Languages
draft-ietf-ltru-registry-09 draft-ietf-ltru-registry-10
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2006. This Internet-Draft will expire on February 5, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes the structure, content, construction, and This document describes the structure, content, construction, and
semantics of language tags for use in cases where it is desirable to semantics of language tags for use in cases where it is desirable to
indicate the language used in an information object. It also indicate the language used in an information object. It also
describes how to register values for use in language tags and the describes how to register values for use in language tags and the
creation of user defined extensions for private interchange. creation of user defined extensions for private interchange.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Language Tag . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Language Tag . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Language Subtag Sources and Interpretation . . . . . . . . 6 2.2 Language Subtag Sources and Interpretation . . . . . . . . 6
2.2.1 Primary Language Subtag . . . . . . . . . . . . . . . 7 2.2.1 Primary Language Subtag . . . . . . . . . . . . . . . 8
2.2.2 Extended Language Subtags . . . . . . . . . . . . . . 9 2.2.2 Extended Language Subtags . . . . . . . . . . . . . . 10
2.2.3 Script Subtag . . . . . . . . . . . . . . . . . . . . 10 2.2.3 Script Subtag . . . . . . . . . . . . . . . . . . . . 10
2.2.4 Region Subtag . . . . . . . . . . . . . . . . . . . . 11 2.2.4 Region Subtag . . . . . . . . . . . . . . . . . . . . 11
2.2.5 Variant Subtags . . . . . . . . . . . . . . . . . . . 13 2.2.5 Variant Subtags . . . . . . . . . . . . . . . . . . . 13
2.2.6 Extension Subtags . . . . . . . . . . . . . . . . . . 14 2.2.6 Extension Subtags . . . . . . . . . . . . . . . . . . 14
2.2.7 Private Use Subtags . . . . . . . . . . . . . . . . . 15 2.2.7 Private Use Subtags . . . . . . . . . . . . . . . . . 15
2.2.8 Pre-Existing RFC 3066 Registrations . . . . . . . . . 16 2.2.8 Pre-Existing RFC 3066 Registrations . . . . . . . . . 16
2.2.9 Classes of Conformance . . . . . . . . . . . . . . . . 16 2.2.9 Classes of Conformance . . . . . . . . . . . . . . . . 16
3. Registry Format and Maintenance . . . . . . . . . . . . . . . 18 3. Registry Format and Maintenance . . . . . . . . . . . . . . . 18
3.1 Format of the IANA Language Subtag Registry . . . . . . . 18 3.1 Format of the IANA Language Subtag Registry . . . . . . . 18
3.2 Maintenance of the Registry . . . . . . . . . . . . . . . 23 3.2 Maintenance of the Registry . . . . . . . . . . . . . . . 23
skipping to change at page 2, line 42 skipping to change at page 2, line 42
4.3.1 Working with Limited Buffer Sizes . . . . . . . . . . 40 4.3.1 Working with Limited Buffer Sizes . . . . . . . . . . 40
4.3.2 Truncation of Language Tags . . . . . . . . . . . . . 42 4.3.2 Truncation of Language Tags . . . . . . . . . . . . . 42
4.4 Canonicalization of Language Tags . . . . . . . . . . . . 42 4.4 Canonicalization of Language Tags . . . . . . . . . . . . 42
4.5 Considerations for Private Use Subtags . . . . . . . . . . 44 4.5 Considerations for Private Use Subtags . . . . . . . . . . 44
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
5.1 Language Subtag Registry . . . . . . . . . . . . . . . . . 46 5.1 Language Subtag Registry . . . . . . . . . . . . . . . . . 46
5.2 Extensions Registry . . . . . . . . . . . . . . . . . . . 47 5.2 Extensions Registry . . . . . . . . . . . . . . . . . . . 47
6. Security Considerations . . . . . . . . . . . . . . . . . . . 48 6. Security Considerations . . . . . . . . . . . . . . . . . . . 48
7. Character Set Considerations . . . . . . . . . . . . . . . . . 49 7. Character Set Considerations . . . . . . . . . . . . . . . . . 49
8. Changes from RFC 3066 . . . . . . . . . . . . . . . . . . . . 50 8. Changes from RFC 3066 . . . . . . . . . . . . . . . . . . . . 50
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.1 Normative References . . . . . . . . . . . . . . . . . . . 54 9.1 Normative References . . . . . . . . . . . . . . . . . . . 55
9.2 Informative References . . . . . . . . . . . . . . . . . . 55 9.2 Informative References . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 57
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58
B. Examples of Language Tags (Informative) . . . . . . . . . . . 58 B. Examples of Language Tags (Informative) . . . . . . . . . . . 59
Intellectual Property and Copyright Statements . . . . . . . . 61 Intellectual Property and Copyright Statements . . . . . . . . 62
1. Introduction 1. Introduction
Human beings on our planet have, past and present, used a number of Human beings on our planet have, past and present, used a number of
languages. There are many reasons why one would want to identify the languages. There are many reasons why one would want to identify the
language used when presenting or requesting information. language used when presenting or requesting information.
User's language preferences often need to be identified so that User's language preferences often need to be identified so that
appropriate processing can be applied. For example, the user's appropriate processing can be applied. For example, the user's
language preferences in a Web browser can be used to select Web pages language preferences in a Web browser can be used to select Web pages
skipping to change at page 3, line 41 skipping to change at page 3, line 41
dialect, writing system, or orthography used in a document or dialect, writing system, or orthography used in a document or
resource may enable the user to obtain information in a form that resource may enable the user to obtain information in a form that
they can understand, or important in processing or rendering the they can understand, or important in processing or rendering the
given content into an appropriate form or style. given content into an appropriate form or style.
This document specifies a particular identifier mechanism (the This document specifies a particular identifier mechanism (the
language tag) and a registration function for values to be used to language tag) and a registration function for values to be used to
form tags. It also defines a mechanism for private use values and form tags. It also defines a mechanism for private use values and
future extension. future extension.
This document replaces RFC 3066, which replaced RFC 1766. For a list This document replaces [RFC3066], which replaced [RFC1766]. For a
of changes in this document, see Section 8. list of changes in this document, see Section 8.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. The Language Tag 2. The Language Tag
The language tag always defines a language as used (which includes Language tags are used to help identify languages, whether spoken,
being spoken, written, signed, or otherwise signaled) by human beings written, signed, or otherwise signaled, for the purpose of
for communication of information to other human beings. Computer communication. This includes constructed and artificial languages,
languages such as programming languages are explicitly excluded. but excludes languages not intended primarily for human
communication, such as programming languages.
2.1 Syntax 2.1 Syntax
The language tag is composed of one or more parts or "subtags". Each The language tag is composed of one or more parts or "subtags". Each
subtag consists of a sequence of alpha-numeric characters. Subtags subtag consists of a sequence of alpha-numeric characters. Subtags
are distinguished and separated from one another by a hyphen ("-", are distinguished and separated from one another by a hyphen ("-",
ABNF %x2D). A language tag consists of a "primary language" subtag ABNF [RFC2234bis] %x2D). A language tag consists of a "primary
and a (possibly empty) series of subsequent subtags, each of which language" subtag and a (possibly empty) series of subsequent subtags,
refines or narrows the range of language identified by the overall each of which refines or narrows the range of language identified by
tag. the overall tag.
Each type of subtag is distinguished by length, position in the tag, Each type of subtag is distinguished by length, position in the tag,
and content: subtags can be recognized solely by these features. and content: subtags can be recognized solely by these features.
This makes it possible to construct a parser that can extract and This makes it possible to construct a parser that can extract and
assign some semantic information to the subtags, even if the specific assign some semantic information to the subtags, even if the specific
subtag values are not recognized. Thus a parser need not have an up- subtag values are not recognized. Thus a parser need not have an up-
to-date copy (or any copy at all) of the subtag registry to perform to-date copy (or any copy at all) of the subtag registry to perform
most searching and matching operations. most searching and matching operations.
The syntax of the language tag in ABNF [RFC2234bis] is: The syntax of the language tag in ABNF [RFC2234bis] is:
Language-Tag = (lang Language-Tag = langtag
*3("-" extlang) / privateuse ; private use tag
/ grandfathered ; grandfathered registrations
langtag = (language
["-" script] ["-" script]
["-" region] ["-" region]
*("-" variant) *("-" variant)
*("-" extension) *("-" extension)
["-" privateuse]) ["-" privateuse])
/ privateuse ; private use tag
/ grandfathered ; grandfathered registrations
lang = 2*4ALPHA ; shortest ISO 639 code language = (2*3ALPHA [ extlang ]) ; shortest ISO 639 code
/ registered-lang / 4ALPHA ; reserved for future use
extlang = 3ALPHA ; reserved for future use / 5*8ALPHA ; registered language subtag
extlang = *3("-" 3ALPHA) ; reserved for future use
script = 4ALPHA ; ISO 15924 code script = 4ALPHA ; ISO 15924 code
region = 2ALPHA ; ISO 3166 code region = 2ALPHA ; ISO 3166 code
/ 3DIGIT ; UN country number / 3DIGIT ; UN M.49 code
variant = 5*8alphanum ; registered variants variant = 5*8alphanum ; registered variants
/ ( DIGIT 3alphanum ) / ( DIGIT 3alphanum )
extension = singleton 1*("-" (2*8alphanum)) extension = singleton 1*("-" (2*8alphanum))
privateuse = ("x"/"X") 1*("-" (1*8alphanum))
singleton = %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT singleton = %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT
; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9" ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9"
; Single letters: x/X is reserved for private use ; Single letters: x/X is reserved for private use
registered-lang = 4*8ALPHA ; registered language subtag
privateuse = ("x"/"X") 1*("-" (1*8alphanum))
grandfathered = 1*3ALPHA 1*2("-" (2*8alphanum)) grandfathered = 1*3ALPHA 1*2("-" (2*8alphanum))
; grandfathered registration ; grandfathered registration
; Note: i is the only singleton ; Note: i is the only singleton
; that starts a grandfathered tag ; that starts a grandfathered tag
alphanum = (ALPHA / DIGIT) ; letters and numbers alphanum = (ALPHA / DIGIT) ; letters and numbers
Figure 1: Language Tag ABNF Figure 1: Language Tag ABNF
Note: There is a subtlety in the ABNF for 'variant': variants Note: There is a subtlety in the ABNF for 'variant': variants
starting with a digit MAY be four characters long, while those starting with a digit MAY be four characters long, while those
starting with a letter MUST be at least five characters long. starting with a letter MUST be at least five characters long.
All subtags have a maximum length of eight characters and whitespace All subtags have a maximum length of eight characters and whitespace
is not permitted in a language tag. For examples of language tags, is not permitted in a language tag. For examples of language tags,
skipping to change at page 5, line 49 skipping to change at page 6, line 11
Note: There is a subtlety in the ABNF for 'variant': variants Note: There is a subtlety in the ABNF for 'variant': variants
starting with a digit MAY be four characters long, while those starting with a digit MAY be four characters long, while those
starting with a letter MUST be at least five characters long. starting with a letter MUST be at least five characters long.
All subtags have a maximum length of eight characters and whitespace All subtags have a maximum length of eight characters and whitespace
is not permitted in a language tag. For examples of language tags, is not permitted in a language tag. For examples of language tags,
see Appendix B. see Appendix B.
Note that although [RFC2234bis] refers to octets, the language tags Note that although [RFC2234bis] refers to octets, the language tags
described in this document are sequences of characters from the US- described in this document are sequences of characters from the US-
ASCII repertoire. Language tags MAY be used in documents and ASCII [ISO646] repertoire. Language tags MAY be used in documents
applications that use other encodings, so long as these encompass the and applications that use other encodings, so long as these encompass
US-ASCII repertoire. An example of this would be an XML document the US-ASCII repertoire. An example of this would be an XML document
that uses the UTF-16LE [RFC2781] encoding of [Unicode]. that uses the UTF-16LE [RFC2781] encoding of [Unicode].
The tags and their subtags, including private use and extensions, are The tags and their subtags, including private use and extensions, are
to be treated as case insensitive: there exist conventions for the to be treated as case insensitive: there exist conventions for the
capitalization of some of the subtags, but these MUST not be taken to capitalization of some of the subtags, but these MUST NOT be taken to
carry meaning. carry meaning.
For example: For example:
o [ISO639-1] recommends that language codes be written in lower case o [ISO639-1] recommends that language codes be written in lower case
('mn' Mongolian). ('mn' Mongolian).
o [ISO3166] recommends that country codes be capitalized ('MN' o [ISO3166-1] recommends that country codes be capitalized ('MN'
Mongolia). Mongolia).
o [ISO15924] recommends that script codes use lower case with the o [ISO15924] recommends that script codes use lower case with the
initial letter capitalized ('Cyrl' Cyrillic). initial letter capitalized ('Cyrl' Cyrillic).
However, in the tags defined by this document, the uppercase US-ASCII However, in the tags defined by this document, the uppercase US-ASCII
letters in the range 'A' through 'Z' are considered equivalent and letters in the range 'A' through 'Z' are considered equivalent and
mapped directly to their US-ASCII lowercase equivalents in the range mapped directly to their US-ASCII lowercase equivalents in the range
'a' through 'z'. Thus the tag "mn-Cyrl-MN" is not distinct from "MN- 'a' through 'z'. Thus the tag "mn-Cyrl-MN" is not distinct from "MN-
cYRL-mn" or "mN-cYrL-Mn" (or any other combination) and each of these cYRL-mn" or "mN-cYrL-Mn" (or any other combination) and each of these
skipping to change at page 9, line 26 skipping to change at page 9, line 37
well as the canonical nature of subtags defined by this document, the well as the canonical nature of subtags defined by this document, the
ISO 639 Registration Authority Joint Advisory Committee (ISO 639/ ISO 639 Registration Authority Joint Advisory Committee (ISO 639/
RA-JAC) has included the following statement in [iso639.principles]: RA-JAC) has included the following statement in [iso639.principles]:
"A language code already in ISO 639-2 at the point of freezing ISO "A language code already in ISO 639-2 at the point of freezing ISO
639-1 shall not later be added to ISO 639-1. This is to ensure 639-1 shall not later be added to ISO 639-1. This is to ensure
consistency in usage over time, since users are directed in Internet consistency in usage over time, since users are directed in Internet
applications to employ the alpha-3 code when an alpha-2 code for that applications to employ the alpha-3 code when an alpha-2 code for that
language is not available." language is not available."
In order to avoid instability of the canonical form of tags, if a two In order to avoid instability in the canonical form of tags, if a two
character code is added to ISO 639-1 for a language for which a three character code is added to ISO 639-1 for a language for which a three
character code was already included in ISO 639-2, the two character character code was already included in ISO 639-2, the two character
code will not be added as a subtag in the registry. See Section 3.3. code MUST NOT be registered. See Section 3.3.
For example, if some content were tagged with 'haw' (Hawaiian), which For example, if some content were tagged with 'haw' (Hawaiian), which
currently has no two character code, the tag would not be invalidated currently has no two character code, the tag would not be invalidated
if ISO 639-1 were to assign a two character code to the Hawaiian if ISO 639-1 were to assign a two character code to the Hawaiian
language at a later date. language at a later date.
For example, one of the grandfathered IANA registrations is For example, one of the grandfathered IANA registrations is
"i-enochian". The subtag 'enochian' could be registered in the IANA "i-enochian". The subtag 'enochian' could be registered in the IANA
registry as a primary language subtag (assuming that ISO 639 does not registry as a primary language subtag (assuming that ISO 639 does not
register this language first), making tags such as "enochian-AQ" and register this language first), making tags such as "enochian-AQ" and
skipping to change at page 10, line 45 skipping to change at page 11, line 7
2. Script subtags MUST immediately follow the primary language 2. Script subtags MUST immediately follow the primary language
subtag and all extended language subtags and MUST occur before subtag and all extended language subtags and MUST occur before
any other type of subtag described below. any other type of subtag described below.
3. The script subtags 'Qaaa' through 'Qabx' are reserved for private 3. The script subtags 'Qaaa' through 'Qabx' are reserved for private
use in language tags. These subtags correspond to codes reserved use in language tags. These subtags correspond to codes reserved
by ISO 15924 for private use. These codes MAY be used for non- by ISO 15924 for private use. These codes MAY be used for non-
registered script values. Please refer to Section 4.5 for more registered script values. Please refer to Section 4.5 for more
information on private use subtags. information on private use subtags.
4. Script subtags cannot be registered using the process in 4. Script subtags MUST NOT be registered using the process in
Section 3.4 of this document. Variant subtags MAY be considered Section 3.4 of this document. Variant subtags MAY be considered
for registration for that purpose. for registration for that purpose.
5. There MUST be at most one script subtag in a language tag and the 5. There MUST be at most one script subtag in a language tag and the
script subtag SHOULD be omitted when it adds no distinguishing script subtag SHOULD be omitted when it adds no distinguishing
value to the tag or when the primary language subtag's record value to the tag or when the primary language subtag's record
includes a Suppress-Script field listing the applicable script includes a Suppress-Script field listing the applicable script
subtag. subtag.
Example: "sr-Latn" represents Serbian written using the Latin script. Example: "sr-Latn" represents Serbian written using the Latin script.
skipping to change at page 11, line 25 skipping to change at page 11, line 36
appropriate for use throughout a region; for instance, Spanish appropriate for use throughout a region; for instance, Spanish
content tailored to be useful throughout Latin America. content tailored to be useful throughout Latin America.
The following rules apply to the region subtags: The following rules apply to the region subtags:
1. Region subtags MUST follow any language, extended language, or 1. Region subtags MUST follow any language, extended language, or
script subtags and MUST precede all other subtags. script subtags and MUST precede all other subtags.
2. All two character subtags following the primary subtag were 2. All two character subtags following the primary subtag were
defined in the IANA registry according to the assignments found defined in the IANA registry according to the assignments found
in [ISO3166]--"Codes for the representation of names of countries in [ISO3166-1] ("Codes for the representation of names of
and their subdivisions - Part 1: Country codes"--alpha-2 country countries and their subdivisions -- Part 1: Country codes") using
codes or assignments subsequently made by the ISO 3166 the list of alpha-2 country codes, or using assignments
maintenance agency or governing standardization bodies. subsequently made by the ISO 3166 maintenance agency or governing
standardization bodies.
3. All three character subtags consisting of digit (numeric) 3. All three character subtags consisting of digit (numeric)
characters following the primary subtag were defined in the IANA characters following the primary subtag were defined in the IANA
registry according to the assignments found in UN Standard registry according to the assignments found in UN Standard
Country or Area Codes for Statistical Use [UN_M.49] or Country or Area Codes for Statistical Use [UN_M.49] or
assignments subsequently made by the governing standards body. assignments subsequently made by the governing standards body.
Note that not all of the UN M.49 codes are defined in the IANA Note that not all of the UN M.49 codes are defined in the IANA
registry. The following rules define which codes are entered registry. The following rules define which codes are entered
into the registry as valid subtags: into the registry as valid subtags:
skipping to change at page 14, line 16 skipping to change at page 14, line 29
2.2.6 Extension Subtags 2.2.6 Extension Subtags
Extensions provide a mechanism for extending language tags for use in Extensions provide a mechanism for extending language tags for use in
various applications. See: Section 3.6. The following rules apply various applications. See: Section 3.6. The following rules apply
to extensions: to extensions:
1. Extension subtags are separated from the other subtags defined 1. Extension subtags are separated from the other subtags defined
in this document by a single-letter subtag ("singleton"). The in this document by a single-letter subtag ("singleton"). The
singleton MUST be one allocated to a registration authority via singleton MUST be one allocated to a registration authority via
the mechanism described in Section 3.6 and cannot be the letter the mechanism described in Section 3.6 and MUST NOT be the
'x', which is reserved for private use subtag sequences. letter 'x', which is reserved for private use subtag sequences.
2. Note: Private use subtag sequences starting with the singleton 2. Note: Private use subtag sequences starting with the singleton
subtag 'x' are described below. subtag 'x' are described below.
3. An extension MUST follow at least a primary language subtag. 3. An extension MUST follow at least a primary language subtag.
That is, a language tag cannot begin with an extension. That is, a language tag cannot begin with an extension.
Extensions extend language tags, they do not override or replace Extensions extend language tags, they do not override or replace
them. For example, "a-value" is not a well-formed language tag, them. For example, "a-value" is not a well-formed language tag,
while "de-a-value" is. while "de-a-value" is.
skipping to change at page 16, line 9 skipping to change at page 16, line 21
For example: Users who wished to utilize codes from the Ethnologue For example: Users who wished to utilize codes from the Ethnologue
publication of SIL International for language identification might publication of SIL International for language identification might
agree to exchange tags such as "az-Arab-x-AZE-derbend". This example agree to exchange tags such as "az-Arab-x-AZE-derbend". This example
contains two private use subtags. The first is 'AZE' and the second contains two private use subtags. The first is 'AZE' and the second
is 'derbend'. is 'derbend'.
2.2.8 Pre-Existing RFC 3066 Registrations 2.2.8 Pre-Existing RFC 3066 Registrations
Existing IANA-registered language tags from RFC 1766 and/or RFC 3066 Existing IANA-registered language tags from RFC 1766 and/or RFC 3066
maintain their validity. IANA will maintain these tags in the maintain their validity. These tags will be maintained in the
registry under either the "grandfathered" or "redundant" type. For registry in records of either the "grandfathered" or "redundant"
more information see Section 3.7. type. For more information see Section 3.7.
It is important to note that all language tags formed under the It is important to note that all language tags formed under the
guidelines in this document were either legal, well-formed tags or guidelines in this document were either legal, well-formed tags or
could have been registered under RFC 3066. could have been registered under RFC 3066.
2.2.9 Classes of Conformance 2.2.9 Classes of Conformance
Implementations sometimes need to describe their capabilities with Implementations sometimes need to describe their capabilities with
regard to the rules and practices described in this document. There regard to the rules and practices described in this document. There
are two classes of conforming implementations described by this are two classes of conforming implementations described by this
skipping to change at page 18, line 24 skipping to change at page 18, line 24
subtags will be unambiguous and stable over time. (The meaning of subtags will be unambiguous and stable over time. (The meaning of
private use subtags, of course, is not defined by the IANA registry.) private use subtags, of course, is not defined by the IANA registry.)
The registry defined under this document contains a comprehensive The registry defined under this document contains a comprehensive
list of all of the subtags valid in language tags. This allows list of all of the subtags valid in language tags. This allows
implementers a straightforward and reliable way to validate language implementers a straightforward and reliable way to validate language
tags. tags.
3.1 Format of the IANA Language Subtag Registry 3.1 Format of the IANA Language Subtag Registry
The IANA Language Subtag Registry ("the registry") will consist of a The IANA Language Subtag Registry ("the registry") consists of a text
text file that is machine readable in the format described in this file that is machine readable in the format described in this
section, plus copies of the registration forms approved by the section, plus copies of the registration forms approved by the
Language Subtag Reviewer in accordance with the process described in Language Subtag Reviewer in accordance with the process described in
Section 3.4. With the exception of the registration forms for Section 3.4. With the exception of the registration forms for
grandfathered and redundant tags, no registration records will be grandfathered and redundant tags, no registration records will be
maintained for the initial set of subtags. maintained for the initial set of subtags.
The registry will be in a modified record-jar format text file The registry is in a modified record-jar format text file [record-
[record-jar]. Lines are limited to 72 characters, including all jar]. Lines are limited to 72 characters, including all whitespace.
whitespace.
Records are separated by lines containing only the sequence "%%" Records are separated by lines containing only the sequence "%%"
(%x25.25). (%x25.25).
Each field can be viewed as a single, logical line of ASCII Each field can be viewed as a single, logical line of ASCII
characters, comprising a field-name and a field-body separated by a characters, comprising a field-name and a field-body separated by a
COLON character (%x3A). For convenience, the field-body portion of COLON character (%x3A). For convenience, the field-body portion of
this conceptual entity can be split into a multiple-line this conceptual entity can be split into a multiple-line
representation; this is called "folding". The format of the registry representation; this is called "folding". The format of the registry
is described by the following ABNF (per [RFC2234bis]): is described by the following ABNF (per [RFC2234bis]):
registry = record *("%%" CRLF record) registry = record *("%%" CRLF record)
record = 1*( field-name *SP ":" *SP field-body CRLF ) record = 1*( field-name *SP ":" *SP field-body CRLF )
field-name = *(ALPHA / DIGIT / "-") field-name = (ALPHA / DIGIT)[*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)]
field-body = *(ASCCHAR/LWSP) field-body = *(ASCCHAR/LWSP)
ASCCHAR = %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26 ASCCHAR = %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26
UNICHAR = "&#x" 2*6HEXDIG ";" UNICHAR = "&#x" 2*6HEXDIG ";"
The sequence '..' (%x2E.2E) in a field-body denotes a range of The sequence '..' (%x2E.2E) in a field-body denotes a range of
values. Such a range represents all subtags of the same length that values. Such a range represents all subtags of the same length that
are alphabetically within that range, including the values explicitly are alphabetically within that range, including the values explicitly
mentioned. For example 'a..c' denotes the values 'a', 'b', and 'c'. mentioned. For example 'a..c' denotes the values 'a', 'b', and 'c'.
Characters from outside the US-ASCII repertoire, as well as the Characters from outside the US-ASCII[ISO646] repertoire, as well as
AMPERSAND character ("&", %x26) when it occurs in a field-body are the AMPERSAND character ("&", %x26) when it occurs in a field-body
represented by a "Numeric Character Reference" using hexadecimal are represented by a "Numeric Character Reference" using hexadecimal
notation in the style used by [XML10] (see notation in the style used by [XML10] (see
<http://www.w3.org/TR/REC-xml/#dt-charref>). This consists of the <http://www.w3.org/TR/REC-xml/#dt-charref>). This consists of the
sequence "&#x" (%x26.23.78) followed by a hexadecimal representation sequence "&#x" (%x26.23.78) followed by a hexadecimal representation
of the character's code point in [ISO10646] followed by a closing of the character's code point in [ISO10646] followed by a closing
semicolon (%x3B). For example, the EURO SIGN, U+20AC, would be semicolon (%x3B). For example, the EURO SIGN, U+20AC, would be
represented by the sequence "&#x20AC;". Note that the hexadecimal represented by the sequence "&#x20AC;". Note that the hexadecimal
notation MAY have between two and six digits. notation MAY have between two and six digits.
All fields whose field-body contains a date value use the "full-date" All fields whose field-body contains a date value use the "full-date"
format specified in [RFC3339]. For example: "2004-06-28" represents format specified in [RFC3339]. For example: "2004-06-28" represents
skipping to change at page 19, line 48 skipping to change at page 19, line 47
o 'Type' o 'Type'
* Type's field-value MUST consist of one of the following * Type's field-value MUST consist of one of the following
strings: "language", "extlang", "script", "region", "variant", strings: "language", "extlang", "script", "region", "variant",
"grandfathered", and "redundant" and denotes the type of tag or "grandfathered", and "redundant" and denotes the type of tag or
subtag. subtag.
o Either 'Subtag' or 'Tag' o Either 'Subtag' or 'Tag'
* Subtag's field-value contains the subtag being defined. This * Subtag's field-value contains the subtag being defined. This
field MUST only appear in records of whose Type has one of field MUST only appear in records of whose 'Type' has one of
these values: "language", "extlang", "script", "region", or these values: "language", "extlang", "script", "region", or
"variant". "variant".
* Tag's field-value contains a complete language tag. This field * Tag's field-value contains a complete language tag. This field
MUST only appear in records whose Type has one of these values: MUST only appear in records whose 'Type' has one of these
"grandfathered" or "redundant". values: "grandfathered" or "redundant".
o Description o Description
* Description's field-value contains a non-normative description * Description's field-value contains a non-normative description
of the subtag or tag. of the subtag or tag.
o Added o Added
* Added's field-value contains the date the record was added to * Added's field-value contains the date the record was added to
the registry. the registry.
skipping to change at page 22, line 26 skipping to change at page 22, line 26
Records that contain a 'Preferred-Value' field MUST also have a Records that contain a 'Preferred-Value' field MUST also have a
'Deprecated' field. This field contains a date of deprecation. Thus 'Deprecated' field. This field contains a date of deprecation. Thus
a language tag processor can use the registry to construct the valid, a language tag processor can use the registry to construct the valid,
non-deprecated set of subtags for a given date. In addition, for any non-deprecated set of subtags for a given date. In addition, for any
given tag, a processor can construct the set of valid language tags given tag, a processor can construct the set of valid language tags
that correspond to that tag for all dates up to the date of the that correspond to that tag for all dates up to the date of the
registry. The ability to do these mappings MAY be beneficial to registry. The ability to do these mappings MAY be beneficial to
applications that are matching, selecting, for filtering content applications that are matching, selecting, for filtering content
based on its language tags. based on its language tags.
Note that 'Preferred-Value' mappings in records of type 'region' MAY Note that 'Preferred-Value' mappings in records of type 'region'
NOT represent exactly the same meaning as the original value. There sometimes do not represent exactly the same meaning as the original
are many reasons for a country code to be changed and the effect this value. There are many reasons for a country code to be changed and
has on the formation of language tags will depend on the nature of the effect this has on the formation of language tags will depend on
the change in question. the nature of the change in question.
In particular, the 'Preferred-Value' field does not imply retagging In particular, the 'Preferred-Value' field does not imply retagging
content that uses the affected subtag. content that uses the affected subtag.
The field 'Preferred-Value' MUST NOT be modified once created in the The field 'Preferred-Value' MUST NOT be modified once created in the
registry. The field MAY be added to records of type "grandfathered" registry. The field MAY be added to records of type "grandfathered"
and "region" according to the rules in Section 3.2. Otherwise the and "region" according to the rules in Section 3.2. Otherwise the
field MUST NOT be added to any record already in the registry. field MUST NOT be added to any record already in the registry.
The 'Preferred-Value' field in records of type "grandfathered" and The 'Preferred-Value' field in records of type "grandfathered" and
skipping to change at page 23, line 20 skipping to change at page 23, line 20
the tag "fr-1996" is an inappropriate choice. the tag "fr-1996" is an inappropriate choice.
The field of type 'Prefix' MUST NOT be removed from any record. The The field of type 'Prefix' MUST NOT be removed from any record. The
field-value for this type of field MUST NOT be modified. field-value for this type of field MUST NOT be modified.
The field 'Comments' MAY appear more than once per record. This The field 'Comments' MAY appear more than once per record. This
field MAY be inserted or changed via the registration process and no field MAY be inserted or changed via the registration process and no
guarantee of stability is provided. The content of this field is not guarantee of stability is provided. The content of this field is not
restricted, except by the need to register the information, the restricted, except by the need to register the information, the
suitability of the request, and by reasonable practical size suitability of the request, and by reasonable practical size
limitations. Long screeds about a particular subtag are frowned limitations. Long texts about a particular subtag are frowned upon.
upon.
The field 'Suppress-Script' MUST only appear in records whose 'Type' The field 'Suppress-Script' MUST only appear in records whose 'Type'
field-value is 'language'. This field MAY appear at most one time in field-value is 'language'. This field MUST NOT appear more than one
a record. This field indicates a script used to write the time in a record. This field indicates a script used to write the
overwhelming majority of documents for the given language and which overwhelming majority of documents for the given language and which
therefore adds no distinguishing information to a language tag. It therefore adds no distinguishing information to a language tag. It
helps ensure greater compatibility between the language tags helps ensure greater compatibility between the language tags
generated according to the rules in this document and language tags generated according to the rules in this document and language tags
and tag processors or consumers based on RFC 3066. For example, and tag processors or consumers based on RFC 3066. For example,
virtually all Icelandic documents are written in the Latin script, virtually all Icelandic documents are written in the Latin script,
making the subtag 'Latn' redundant in the tag "is-Latn". making the subtag 'Latn' redundant in the tag "is-Latn".
3.2 Maintenance of the Registry 3.2 Maintenance of the Registry
Maintenance of the registry requires that as codes are assigned or Maintenance of the registry requires that as codes are assigned or
withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language
Subtag Reviewer will evaluate each change, determine whether it Subtag Reviewer MUST evaluate each change, determine whether it
conflicts with existing registry entries, and submit the information conflicts with existing registry entries, and submit the information
to IANA for inclusion in the registry. If an change takes place and to IANA for inclusion in the registry. If an change takes place and
the Language Subtag Reviewer does not do this in a timely manner, the Language Subtag Reviewer does not do this in a timely manner,
then any interested party MAY use the procedure in Section 3.4 to then any interested party MAY use the procedure in Section 3.4 to
register the appropriate update. register the appropriate update.
Note: The redundant and grandfathered entries together are the Note: The redundant and grandfathered entries together are the
complete list of tags registered under [RFC3066]. The redundant tags complete list of tags registered under [RFC3066]. The redundant tags
are those that can now be formed using the subtags defined in the are those that can now be formed using the subtags defined in the
registry together with the rules of Section 2.2. The grandfathered registry together with the rules of Section 2.2. The grandfathered
entries are those that can never be legal under those same entries are those that can never be legal under those same
provisions. provisions.
The set of redundant and grandfathered tags is permanent and stable: The set of redundant and grandfathered tags is permanent and stable:
new entries in this section MUST NOT be added and existing entries
no new entries will be added and none of the entries will be removed. MUST NOT be removed. Records of type 'grandfathered' MAY have their
Records of type 'grandfathered' MAY have their type converted to type converted to 'redundant': see Section 3.7 for more information.
'redundant': see Section 3.7 for more information.
RFC 3066 tags that were deprecated prior to the adoption of this RFC 3066 tags that were deprecated prior to the adoption of this
document are part of the list of grandfathered tags and their document are part of the list of grandfathered tags and their
component subtags were not included as registered variants (although component subtags were not included as registered variants (although
they remain eligible for registration). For example, the tag "art- they remain eligible for registration). For example, the tag "art-
lojban" was deprecated in favor of the language subtag 'jbo'. lojban" was deprecated in favor of the language subtag 'jbo'.
The Language Subtag Reviewer MUST ensure that new subtags meet the The Language Subtag Reviewer MUST ensure that new subtags meet the
requirements in Section 4.1 or submit an appropriate alternate subtag requirements in Section 4.1 or submit an appropriate alternate subtag
as described in that section. When either a change or addition to as described in that section. When either a change or addition to
skipping to change at page 26, line 14 skipping to change at page 26, line 14
9. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are 9. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are
withdrawn by their respective maintenance or registration withdrawn by their respective maintenance or registration
authority remain valid in language tags. A 'Deprecated' field authority remain valid in language tags. A 'Deprecated' field
containing the date of withdrawal is added to the record. If a containing the date of withdrawal is added to the record. If a
new record of the same type is added that represents a new record of the same type is added that represents a
replacement value, then a 'Preferred-Value' field MAY also be replacement value, then a 'Preferred-Value' field MAY also be
added. The registration process MAY be used to add comments added. The registration process MAY be used to add comments
about the withdrawal of the code by the respective standard. about the withdrawal of the code by the respective standard.
1. The region code 'TL' was assigned to the country 'Timor- Example The region code 'TL' was assigned to the country 'Timor-
Leste', replacing the code 'TP' (which was assigned to 'East Leste', replacing the code 'TP' (which was assigned to 'East
Timor' when it was under administration by Portugal). The Timor' when it was under administration by Portugal). The
subtag 'TP' remains valid in language tags, but its record subtag 'TP' remains valid in language tags, but its record
contains the a 'Preferred-Value' of 'TL' and its field contains the a 'Preferred-Value' of 'TL' and its field
'Deprecated' contains the date the new code was assigned 'Deprecated' contains the date the new code was assigned
('2004-07-06'). ('2004-07-06').
10. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict 10. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict
with existing subtags of the associated type, including subtags with existing subtags of the associated type, including subtags
that are deprecated, MUST NOT be entered into the registry. The that are deprecated, MUST NOT be entered into the registry. The
skipping to change at page 29, line 40 skipping to change at page 29, line 40
Variant and extlang subtags are always registered for use with a Variant and extlang subtags are always registered for use with a
particular range of language tags. For example, the subtag 'rozaj' particular range of language tags. For example, the subtag 'rozaj'
is intended for use with language tags that start with the primary is intended for use with language tags that start with the primary
language subtag "sl", since Resian is a dialect of Slovenian. Thus language subtag "sl", since Resian is a dialect of Slovenian. Thus
the subtag 'rozaj' could be included in tags such as "sl-Latn-rozaj" the subtag 'rozaj' could be included in tags such as "sl-Latn-rozaj"
or "sl-IT-rozaj". This information is stored in the "Prefix" field or "sl-IT-rozaj". This information is stored in the "Prefix" field
in the registry. Variant registration requests are REQUIRED to in the registry. Variant registration requests are REQUIRED to
include at least one "Prefix" field in the registration form. include at least one "Prefix" field in the registration form.
The 'Prefix' field for a given registered subtag will be maintained The 'Prefix' field for a given registered subtag exists in the IANA
in the IANA registry as a guide to usage. Additional prefixes MAY be registry as a guide to usage. Additional prefixes MAY be added by
added by filing an additional registration form. In that form, the filing an additional registration form. In that form, the "Any other
"Any other relevant information:" field MUST indicate that it is the relevant information:" field MUST indicate that it is the addition of
addition of a prefix. a prefix.
Requests to add a prefix to a variant subtag that imply a different Requests to add a prefix to a variant subtag that imply a different
semantic meaning will probably be rejected. For example, a request semantic meaning will probably be rejected. For example, a request
to add the prefix "de" to the subtag 'nedis' so that the tag "de- to add the prefix "de" to the subtag 'nedis' so that the tag "de-
nedis" represented some German dialect would be rejected. The nedis" represented some German dialect would be rejected. The
'nedis' subtag represents a particular Slovenian dialect and the 'nedis' subtag represents a particular Slovenian dialect and the
additional registration would change the semantic meaning assigned to additional registration would change the semantic meaning assigned to
the subtag. A separate subtag SHOULD be proposed instead. the subtag. A separate subtag SHOULD be proposed instead.
The 'Description' field MUST contain a description of the tag being The 'Description' field MUST contain a description of the tag being
skipping to change at page 30, line 34 skipping to change at page 30, line 34
When the two week period has passed the Language Subtag Reviewer When the two week period has passed the Language Subtag Reviewer
either forwards the record to be inserted or modified to either forwards the record to be inserted or modified to
iana@iana.org according to the procedure described in Section 3.2, or iana@iana.org according to the procedure described in Section 3.2, or
rejects the request because of significant objections raised on the rejects the request because of significant objections raised on the
list or due to problems with constraints in this document (which MUST list or due to problems with constraints in this document (which MUST
be explicitly cited). The reviewer MAY also extend the review period be explicitly cited). The reviewer MAY also extend the review period
in two week increments to permit further discussion. The reviewer in two week increments to permit further discussion. The reviewer
MUST indicate on the list whether the registration has been accepted, MUST indicate on the list whether the registration has been accepted,
rejected, or extended following each two week period. rejected, or extended following each two week period.
Note that the reviewer can raise objections on the list if he or she Note that the reviewer MAY raise objections on the list if he or she
so desires. The important thing is that the objection MUST be made so desires. The important thing is that the objection MUST be made
publicly. publicly.
The applicant is free to modify a rejected application with The applicant is free to modify a rejected application with
additional information and submit it again; this restarts the two additional information and submit it again; this restarts the two
week comment period. week comment period.
Decisions made by the reviewer MAY be appealed to the IESG [RFC2028] Decisions made by the reviewer MAY be appealed to the IESG [RFC2028]
under the same rules as other IETF decisions [RFC2026]. under the same rules as other IETF decisions [RFC2026].
skipping to change at page 31, line 27 skipping to change at page 31, line 27
not intended to exclude particular languages or dialects due to the not intended to exclude particular languages or dialects due to the
size of the speaker population or lack of a standardized orthography. size of the speaker population or lack of a standardized orthography.
Minority languages will be considered equally on their own merits. Minority languages will be considered equally on their own merits.
3.5 Possibilities for Registration 3.5 Possibilities for Registration
Possibilities for registration of subtags or information about Possibilities for registration of subtags or information about
subtags include: subtags include:
o Primary language subtags for languages not listed in ISO 639 that o Primary language subtags for languages not listed in ISO 639 that
are not variants of any listed or registered language can be are not variants of any listed or registered language MAY be
registered. At the time this document was created there were no registered. At the time this document was created there were no
examples of this form of subtag. Before attempting to register a examples of this form of subtag. Before attempting to register a
language subtag, there MUST be an attempt to register the language language subtag, there MUST be an attempt to register the language
with ISO 639. No language subtags will be registered for codes with ISO 639. Subtags MUST NOT be registered for codes that exist
that exist in ISO 639-1 or ISO 639-2, which are under in ISO 639-1 or ISO 639-2, which are under consideration by the
consideration by the ISO 639 maintenance or registration ISO 639 maintenance or registration authorities, or which have
authorities, or which have never been attempted for registration never been attempted for registration with those authorities. If
with those authorities. If ISO 639 has previously rejected a ISO 639 has previously rejected a language for registration, it is
language for registration, it is reasonable to assume that there reasonable to assume that there must be additional very compelling
must be additional very compelling evidence of need before it will evidence of need before it will be registered in the IANA registry
be registered in the IANA registry (to the extent that it is very (to the extent that it is very unlikely that any subtags will be
unlikely that any subtags will be registered of this type). registered of this type).
o Dialect or other divisions or variations within a language, its o Dialect or other divisions or variations within a language, its
orthography, writing system, regional or historical usage, orthography, writing system, regional or historical usage,
transliteration or other transformation, or distinguishing transliteration or other transformation, or distinguishing
variation MAY be registered as variant subtags. An example is the variation MAY be registered as variant subtags. An example is the
'rozaj' subtag (the Resian dialect of Slovenian). 'rozaj' subtag (the Resian dialect of Slovenian).
o The addition or maintenance of fields (generally of an o The addition or maintenance of fields (generally of an
informational nature) in Tag or Subtag records as described in informational nature) in Tag or Subtag records as described in
Section 3.1 and subject to the stability provisions in Section 3.1 and subject to the stability provisions in
skipping to change at page 33, line 20 skipping to change at page 33, line 20
Fax: +1-212-963-0623 Fax: +1-212-963-0623
E-mail: statistics@un.org E-mail: statistics@un.org
URL: http://unstats.un.org/unsd/methods/m49/m49alpha.htm URL: http://unstats.un.org/unsd/methods/m49/m49alpha.htm
3.6 Extensions and Extensions Namespace 3.6 Extensions and Extensions Namespace
Extension subtags are those introduced by single-letter subtags other Extension subtags are those introduced by single-letter subtags other
than 'x'. They are reserved for the generation of identifiers which than 'x'. They are reserved for the generation of identifiers which
contain a language component, and are compatible with applications contain a language component, and are compatible with applications
that understand language tags. For example, they might be used to that understand language tags.
define locale identifiers, which are generally based on language.
The structure and form of extensions are defined by this document so The structure and form of extensions are defined by this document so
that implementations can be created that are forward compatible with that implementations can be created that are forward compatible with
applications that might be created using single-letter subtags in the applications that might be created using single-letter subtags in the
future. In addition, defining a mechanism for maintaining single- future. In addition, defining a mechanism for maintaining single-
letter subtags will lend to the stability of this document by letter subtags will lend stability to this document by reducing the
reducing the likely need for future revisions or updates. likely need for future revisions or updates.
Allocation of a single-letter subtag SHALL take the form of an RFC Single-letter subtags are to be assigned by IANA using the "IETF
defining the name, purpose, processes, and procedures for maintaining Consensus" policy defined by [RFC2434]. This policy requires the
the subtags. The maintaining or registering authority, including development of an RFC, which SHALL define the name, purpose,
name, contact email, discussion list email, and URL location of the processes, and procedures for maintaining the subtags. The
registry MUST be indicated clearly in the RFC. The RFC MUST specify maintaining or registering authority, including name, contact email,
or include each of the following: discussion list email, and URL location of the registry MUST be
indicated clearly in the RFC. The RFC MUST specify or include each
of the following:
o The specification MUST reference the specific version or revision o The specification MUST reference the specific version or revision
of this document that governs its creation and MUST reference this of this document that governs its creation and MUST reference this
section of this document. section of this document.
o The specification and all subtags defined by the specification o The specification and all subtags defined by the specification
MUST follow the ABNF and other rules for the formation of tags and MUST follow the ABNF and other rules for the formation of tags and
subtags as defined in this document. In particular it MUST subtags as defined in this document. In particular it MUST
specify that case is not significant and that subtags MUST NOT specify that case is not significant and that subtags MUST NOT
exceed eight characters in length. exceed eight characters in length.
skipping to change at page 34, line 24 skipping to change at page 34, line 24
in meaning in any substantial way. in meaning in any substantial way.
o The specification MUST include in a separate section the o The specification MUST include in a separate section the
registration form reproduced in this section (below) to be used in registration form reproduced in this section (below) to be used in
registering the extension upon publication as an RFC. registering the extension upon publication as an RFC.
o IANA MUST be informed of changes to the contact information and o IANA MUST be informed of changes to the contact information and
URL for the specification. URL for the specification.
IANA will maintain a registry of allocated single-letter (singleton) IANA will maintain a registry of allocated single-letter (singleton)
subtags. This registry will use the record-jar format described by subtags. This registry MUST use the record-jar format described by
the ABNF in Section 3.1. Upon publication of an extension as an RFC, the ABNF in Section 3.1. Upon publication of an extension as an RFC,
the maintaining authority defined in the RFC MUST forward this the maintaining authority defined in the RFC MUST forward this
registration form to iesg@ietf.org, who will forward the request to registration form to iesg@ietf.org, who MUST forward the request to
iana@iana.org. The maintaining authority of the extension MUST iana@iana.org. The maintaining authority of the extension MUST
maintain the accuracy of the record by sending an updated full copy maintain the accuracy of the record by sending an updated full copy
of the record to iana@iana.org with the subject line "LANGUAGE TAG of the record to iana@iana.org with the subject line "LANGUAGE TAG
EXTENSION UPDATE" whenever content changes. Only the 'Comments', EXTENSION UPDATE" whenever content changes. Only the 'Comments',
'Contact_Email', 'Mailing_List', and 'URL' fields MAY be modified in 'Contact_Email', 'Mailing_List', and 'URL' fields MAY be modified in
these updates. these updates.
Failure to maintain this record, the corresponding registry, or meet Failure to maintain this record, the corresponding registry, or meet
other conditions imposed by this section of this document MAY be other conditions imposed by this section of this document MAY be
appealed to the IESG [RFC2028] under the same rules as other IETF appealed to the IESG [RFC2028] under the same rules as other IETF
skipping to change at page 39, line 25 skipping to change at page 39, line 25
To ensure consistent backward compatibility, this document contains To ensure consistent backward compatibility, this document contains
several provisions to account for potential instability in the several provisions to account for potential instability in the
standards used to define the subtags that make up language tags. standards used to define the subtags that make up language tags.
These provisions mean that no language tag created under the rules in These provisions mean that no language tag created under the rules in
this document will become obsolete. this document will become obsolete.
4.2 Meaning of the Language Tag 4.2 Meaning of the Language Tag
The relationship between the tag and the information it relates to is The relationship between the tag and the information it relates to is
defined by the context in which the tag appears. Accordingly, this defined by the context in which the tag appears. Accordingly, this
section can only give possible examples of its usage. section gives only possible examples of its usage.
o For a single information object, the associated language tags o For a single information object, the associated language tags
might be interpreted as the set of languages that is necessary for might be interpreted as the set of languages that is necessary for
a complete comprehension of the complete object. Example: Plain a complete comprehension of the complete object. Example: Plain
text documents. text documents.
o For an aggregation of information objects, the associated language o For an aggregation of information objects, the associated language
tags could be taken as the set of languages used inside components tags could be taken as the set of languages used inside components
of that aggregation. Examples: Document stores and libraries. of that aggregation. Examples: Document stores and libraries.
skipping to change at page 43, line 10 skipping to change at page 43, line 10
language tags SHOULD always be created or generated in a canonical language tags SHOULD always be created or generated in a canonical
form. form.
A language tag is in canonical form when: A language tag is in canonical form when:
1. The tag is well-formed according the rules in Section 2.1 and 1. The tag is well-formed according the rules in Section 2.1 and
Section 2.2. Section 2.2.
2. Subtags of type 'Region' that have a Preferred-Value mapping in 2. Subtags of type 'Region' that have a Preferred-Value mapping in
the IANA registry (see Section 3.1) SHOULD be replaced with their the IANA registry (see Section 3.1) SHOULD be replaced with their
mapped value. mapped value. Note: In rare cases the mapped value will also
have a Preferred-Value.
3. Redundant or grandfathered tags that have a Preferred-Value 3. Redundant or grandfathered tags that have a Preferred-Value
mapping in the IANA registry (see Section 3.1) MUST be replaced mapping in the IANA registry (see Section 3.1) MUST be replaced
with their mapped value. These items are either deprecated with their mapped value. These items are either deprecated
mappings created before the adoption of this document (such as mappings created before the adoption of this document (such as
the mapping of "no-nyn" to "nn" or "i-klingon" to "tlh") or are the mapping of "no-nyn" to "nn" or "i-klingon" to "tlh") or are
the result of later registrations or additions to this document the result of later registrations or additions to this document
(for example, "zh-guoyu" might be mapped to a language-extlang (for example, "zh-guoyu" might be mapped to a language-extlang
combination such as "zh-cmn" by some future update of this combination such as "zh-cmn" by some future update of this
document). document).
skipping to change at page 43, line 36 skipping to change at page 43, line 37
for compatibility purposes. for compatibility purposes.
5. If more than one extension subtag sequence exists, the extension 5. If more than one extension subtag sequence exists, the extension
sequences are ordered into case-insensitive ASCII order by sequences are ordered into case-insensitive ASCII order by
singleton subtag. singleton subtag.
Example: The language tag "en-A-aaa-B-ccc-bbb-x-xyz" is in canonical Example: The language tag "en-A-aaa-B-ccc-bbb-x-xyz" is in canonical
form, while "en-B-ccc-bbb-A-aaa-X-xyz" is well-formed but not in form, while "en-B-ccc-bbb-A-aaa-X-xyz" is well-formed but not in
canonical form. canonical form.
Example: The language tag "en-NH" (English as used in the New Example: The language tag "en-BU" (English as used in Burma) is not
Hebrides) is not canonical because the 'NH' subtag has a canonical canonical because the 'BU' subtag has a canonical mapping to 'MM'
mapping to 'VU' (Vanuatu), although the tag "en-NH" maintains its (Myanmar), although the tag "en-BU" maintains its validity.
validity.
Canonicalization of language tags does not imply anything about the Canonicalization of language tags does not imply anything about the
use of upper or lowercase letters when processing or comparing use of upper or lowercase letters when processing or comparing
subtags (and as described in Section 2.1). All comparisons MUST be subtags (and as described in Section 2.1). All comparisons MUST be
performed in a case-insensitive manner. performed in a case-insensitive manner.
When performing canonicalization of language tags, processors MAY When performing canonicalization of language tags, processors MAY
regularize the case of the subtags (that is, this process is regularize the case of the subtags (that is, this process is
OPTIONAL), following the case used in the registry. Note that this OPTIONAL), following the case used in the registry. Note that this
corresponds to the following casing rules: uppercase all non-initial corresponds to the following casing rules: uppercase all non-initial
skipping to change at page 44, line 42 skipping to change at page 44, line 42
aaa-bbb-ccc"). However, extension specifications SHOULD be designed aaa-bbb-ccc"). However, extension specifications SHOULD be designed
so that they are tolerant of the typical processes described in so that they are tolerant of the typical processes described in
Section 3.6. Section 3.6.
4.5 Considerations for Private Use Subtags 4.5 Considerations for Private Use Subtags
Private use subtags, like all other subtags, MUST conform to the Private use subtags, like all other subtags, MUST conform to the
format and content constraints in the ABNF. Private use subtags have format and content constraints in the ABNF. Private use subtags have
no meaning outside the private agreement between the parties that no meaning outside the private agreement between the parties that
intend to use or exchange language tags that employ them. The same intend to use or exchange language tags that employ them. The same
subtags could be used with a different meaning under a separate subtags MAY be used with a different meaning under a separate private
private agreement. They SHOULD NOT be used where alternatives exist agreement. They SHOULD NOT be used where alternatives exist and
and SHOULD NOT be used in content or protocols intended for general SHOULD NOT be used in content or protocols intended for general use.
use.
Private use subtags are simply useless for information exchange Private use subtags are simply useless for information exchange
without prior arrangement. The value and semantic meaning of private without prior arrangement. The value and semantic meaning of private
use tags and of the subtags used within such a language tag are not use tags and of the subtags used within such a language tag are not
defined by this document. defined by this document.
Subtags defined in the IANA registry as having a specific private use Subtags defined in the IANA registry as having a specific private use
meaning convey more information that a purely private use tag meaning convey more information that a purely private use tag
prefixed by the singleton subtag 'x'. For applications this prefixed by the singleton subtag 'x'. For applications this
additional information MAY be useful. additional information MAY be useful.
skipping to change at page 46, line 27 skipping to change at page 46, line 27
Upon adoption of this document, the registry will be initialized by a Upon adoption of this document, the registry will be initialized by a
companion document: [initial-registry]. The criteria and process for companion document: [initial-registry]. The criteria and process for
selecting the initial set of records is described in that document. selecting the initial set of records is described in that document.
The initial set of records represents no impact on IANA, since the The initial set of records represents no impact on IANA, since the
work to create it will be performed externally. work to create it will be performed externally.
The new registry MUST be listed under "Language Tags" at The new registry MUST be listed under "Language Tags" at
<http://www.iana.org/numbers.html>, replacing the existing <http://www.iana.org/numbers.html>, replacing the existing
registrations defined by [RFC3066]. The existing set of registration registrations defined by [RFC3066]. The existing set of registration
forms and RFC 3066 registrations will be relabeled as "Language Tags forms and RFC 3066 registrations MUST be relabeled as "Language Tags
(Obsolete)" and maintained (but not added to or modified). (Obsolete)" and maintained (but not added to or modified).
Future work on the Language Subtag Registry will be limited to Future work on the Language Subtag Registry SHALL be limited to
inserting or replacing whole records preformatted for IANA by the inserting or replacing whole records preformatted for IANA by the
Language Subtag Reviewer as described in Section 3.2 of this Language Subtag Reviewer as described in Section 3.2 of this
document. This simplifies IANA's work by limiting it to placing the document. This simplifies IANA's work by limiting it to placing the
text in the appropriate location in the registry. text in the appropriate location in the registry.
Each record will be sent to iana@iana.org with a subject line Each record MUST be sent to iana@iana.org with a subject line
indicating whether the enclosed record is an insertion of a new indicating whether the enclosed record is an insertion of a new
record (indicated by the word "INSERT" in the subject line) or a record (indicated by the word "INSERT" in the subject line) or a
replacement of an existing record (indicated by the word "MODIFY" in replacement of an existing record (indicated by the word "MODIFY" in
the subject line). Records MUST NOT be deleted from the registry. the subject line). Records MUST NOT be deleted from the registry.
IANA MUST place any inserted or modified records into the appropriate IANA MUST place any inserted or modified records into the appropriate
section of the language subtag registry, grouping the records by section of the language subtag registry, grouping the records by
their "Type" field. Inserted records MAY be placed anywhere in the their 'Type' field. Inserted records MAY be placed anywhere in the
appropriate section; there is no guarantee of the order of the appropriate section; there is no guarantee of the order of the
records beyond grouping them together by 'Type'. Modified records records beyond grouping them together by 'Type'. Modified records
MUST overwrite the record they replace. MUST overwrite the record they replace.
Included in any request to insert or modify records MUST be a new Included in any request to insert or modify records MUST be a new
File-Date record. This record MUST be placed first in the registry. File-Date record. This record MUST be placed first in the registry.
In the event that the File-Date record present in the registry has a In the event that the File-Date record present in the registry has a
later date then the record being inserted or modified, the existing later date then the record being inserted or modified, the existing
record MUST be preserved. record MUST be preserved.
5.2 Extensions Registry 5.2 Extensions Registry
The Language Tag Extensions registry will also be generated and sent The Language Tag Extensions registry will also be generated and sent
to IANA as described in Section 3.6. This registry can contain at to IANA as described in Section 3.6. This registry can contain at
most 35 records and thus changes to this registry are expected to be most 35 records and thus changes to this registry are expected to be
very infrequent. very infrequent.
Future work by IANA on the Language Tag Extensions Registry is Future work by IANA on the Language Tag Extensions Registry is
limited to two cases. First, the IESG MAY request that new records limited to two cases. First, the IESG MAY request that new records
be inserted into this registry from time to time. These requests be inserted into this registry from time to time. These requests
will include the record to insert in the exact format described in MUST include the record to insert in the exact format described in
Section 3.6. In addition, there MAY be occasional requests from the Section 3.6. In addition, there MAY be occasional requests from the
maintaining authority for a specific extension to update the contact maintaining authority for a specific extension to update the contact
information or URLs in the record. These requests MUST include the information or URLs in the record. These requests MUST include the
complete, updated record. IANA is not responsible for validating the complete, updated record. IANA is not responsible for validating the
information provided, only that it is properly formatted. It should information provided, only that it is properly formatted. It should
reasonably be seen to come from the maintaining authority named in reasonably be seen to come from the maintaining authority named in
the record present in the registry. the record present in the registry.
6. Security Considerations 6. Security Considerations
skipping to change at page 49, line 18 skipping to change at page 49, line 18
characters A-Z, a-z, 0-9, and HYPHEN-MINUS, which are present in most characters A-Z, a-z, 0-9, and HYPHEN-MINUS, which are present in most
character sets, so the composition of language tags should not have character sets, so the composition of language tags should not have
any character set issues. any character set issues.
Rendering of characters based on the content of a language tag is not Rendering of characters based on the content of a language tag is not
addressed in this memo. Historically, some languages have relied on addressed in this memo. Historically, some languages have relied on
the use of specific character sets or other information in order to the use of specific character sets or other information in order to
infer how a specific character should be rendered (notably this infer how a specific character should be rendered (notably this
applies to language and culture specific variations of Han ideographs applies to language and culture specific variations of Han ideographs
as used in Japanese, Chinese, and Korean). When language tags are as used in Japanese, Chinese, and Korean). When language tags are
applied to spans of text, rendering engines can use that information applied to spans of text, rendering engines sometimes use that
in deciding which font to use in the absence of other information, information in deciding which font to use in the absence of other
particularly where languages with distinct writing traditions use the information, particularly where languages with distinct writing
same characters. traditions use the same characters.
8. Changes from RFC 3066 8. Changes from RFC 3066
The main goals for this revision of language tags were the following: The main goals for this revision of language tags were the following:
*Compatibility.* All RFC 3066 language tags (including those in the *Compatibility.* All RFC 3066 language tags (including those in the
IANA registry) remain valid in this specification. The changes in IANA registry) remain valid in this specification. The changes in
this document represent additional constraints on language tags. this document represent additional constraints on language tags.
That is, in no case is the syntax more permissive and processors That is, in no case is the syntax more permissive and processors
based on the RFC 3066 ABNF (such as those described in [XMLSchema]) based on the ABNF and other provisions of RFC 3066 (such as those
will be able to process the tags described by this document. In described in [XMLSchema]) will be able to process the tags described
addition, this document defines language tags in such as way as to by this document. In addition, this document defines language tags
ensure future compatibility. in such as way as to ensure future compatibility.
*Stability.* Because of changes in the past in the underlying ISO *Stability.* Because of changes in the past in the underlying ISO
standards, a valid RFC 3066 language tag could become invalid or have standards, a valid RFC 3066 language tag could become invalid or have
its meaning change. This has the potential of invalidating content its meaning change. This has the potential of invalidating content
that may have an extensive shelf-life. In this specification, once a that may have an extensive shelf-life. In this specification, once a
language tag is valid, it remains valid forever. language tag is valid, it remains valid forever.
*Validity.* The structure of language tags defined by this document *Validity.* The structure of language tags defined by this document
makes it possible to determine if a particular tag is well-formed makes it possible to determine if a particular tag is well-formed
without regard for the actual content or "meaning" of the tag as a without regard for the actual content or "meaning" of the tag as a
skipping to change at page 52, line 39 skipping to change at page 52, line 39
region subtags respectively. region subtags respectively.
o Adds a well-defined extension mechanism. o Adds a well-defined extension mechanism.
o Defines an extended language subtag, possibly for use with certain o Defines an extended language subtag, possibly for use with certain
anticipated features of ISO 639-3. anticipated features of ISO 639-3.
Ed Note: The following items are provided for the convenience of Ed Note: The following items are provided for the convenience of
reviewers and will be removed from the final document. reviewers and will be removed from the final document.
Changes between draft-ietf-ltru-registry-08 and this version are: Changes between draft-ietf-ltru-registry-09 and this version are:
o Added a reference URI to the editor's address. (F.Ellermann) o Incorporated John Cowan's list of nits selectively by looking at
the context. RFC 2119 word changes listed. (#1026
thread)(J.Cowan)
o Various nit fixings. * could be used => MAY in Section 4.5
o Fixed rule #11 in Section 3.3 to allow UN M.49 codes to be * cannot => MUST NOT in Section 3.6
registered in extreme situations (#1026) (F.Ellermann, R.Presuhn,
etc.)
o Added more cautionary text about private use subtags to * can raise objections => MAY in Section 3.4
Section 4.5. (#1061) (D.Pierce)
o Regularized "private-use" to always use the form "private use".
(A.Phillips)
o Additional wordsmithing on rule #11 in Section 3.3. (F.Ellermann) * can be registered => MAY in Section 3.5
* will not be added => MUST in Section 2.2.1
9. References * will evaluate => MUST in Section 3.2
9.1 Normative References * 'no new entries will be added and none of the entries removed'
made normative in Section 3.2
[ISO639-1] * 'No subtags will be registered' => 'Subtags MUST NOT be
International Organization for Standardization, "ISO 639- registered' in Section 3.5
1:2002, Codes for the representation of names of languages
-- Part 1: Alpha-2 code", ISO Standard 639, 2002, <ISO
639-1>.
[ISO639-2] * will use, will forward => MUST in Section 3.6
International Organization for Standardization, "ISO 639-
2:1998 - Codes for the representation of names of
languages -- Part 2: Alpha-3 code - edition 1",
August 1988, <ISO 639-2>.
[ISO15924] * will be relabeled, will be sent => MUST in Section 5.1
ISO TC46/WG3, "ISO 15924:2003 (E/F) - Codes for the
representation of names of scripts", January 2004, <ISO
15924>.
[ISO3166] International Organization for Standardization, "Codes for * will be limited => SHALL in Section 5.1
the representation of names of countries, 3rd edition",
ISO Standard 3166, August 1988, <ISO 3166>.
[UN_M.49] Statistical Division, United Nations, "Standard Country or * will include => MUST in Section 5.2
Area Codes for Statistical Use", UN Standard Country or
Area Codes for Statistical Use, Revision 4 (United Nations o Changed the introductory paragraph to avoid the loaded word
publication, Sales No. 98.XVII.9, June 1999, <UN M.49>. "defined" (M.Duerst, JFC Morfin)
o Added clarification to the "Compatibility" paragraph just above
(M.Davis)
o Modified the introduction to Section 2. (M.Gunn)
o Added formal reference links to [RFC3066] and [RFC1766] in
Section 1 (S.Hollenbeck)
o Added a reference to [RFC2234bis] to the reference to ABNF %2D in
Section 2.1 (S.Hollenbeck)
o Added a normative reference to [ISO646] and referenced it in
Section 2.1 (S.Hollenbeck)
o Changed "MUST not" to "MUST NOT" in Section 2.1 (S.Hollenbeck)
o Changed "MAY NOT" (which isn't RFC 2119 defined) to read
"...records of type 'region' sometimes does not represent..." in
Section 3.1 (S.Hollenbeck)
o Referenced RFC2434 and "IETF Consensus" policy in Section 3.6
(S.Hollenbeck)
o Adjusted an introduction paragraph in order to have a forward
reference to the subtag registry. (P.Constable)
o Beautified the ABNF (K.Karlsson)
o Beautified the registration form artwork by adding some indention
(F.Ellermann)
o Other minor editorial nits. (F.Ellermann)
o Removed the "locale identifiers" sentence. (#1067) (R.Presuhn)
9. References
9.1 Normative References
[ISO10646] [ISO10646]
International Organization for Standardization, "ISO/IEC International Organization for Standardization, "ISO/IEC
10646-1:2000. Information technology -- Universal 10646:2003. Information technology -- Universal Multiple-
Multiple-Octet Coded Character Set (UCS) -- Part 1: Octet Coded Character Set (UCS), as, from time to time,
Architecture and Basic Multilingual Plane and ISO/IEC amended, replaced by a new edition or expanded by the
10646-2:2001. Information technology -- Universal addition of new parts", 2003.
Multiple-Octet Coded Character Set (UCS) -- Part 2:
Supplementary Planes, as, from time to time, amended,
replaced by a new edition or expanded by the addition of
new parts", 2000, <ISO/IEC 10646>.
[RFC2234bis] [ISO15924]
Crocker, D. and P. Overell, "Augmented BNF for Syntax International Organization for Standardization, "ISO
Specifications: ABNF", draft-crocker-abnf-rfc2234bis-00 15924:2004. Information and documentation -- Codes for the
(work in progress), March 2005. representation of names of scripts", January 2004.
[ISO3166-1]
International Organization for Standardization, "ISO 3166-
1:1997. Codes for the representation of names of
countries and their subdivisions -- Part 1: Country
codes", 1997.
[ISO639-1]
International Organization for Standardization, "ISO 639-
1:2002. Codes for the representation of names of languages
-- Part 1: Alpha-2 code", 2002.
[ISO639-2]
International Organization for Standardization, "ISO 639-
2:1998. Codes for the representation of names of languages
-- Part 2: Alpha-3 code, first edition", 1998.
[ISO646] ISO/IEC 646 JTC 1/SC 2, "ISO/IEC 646:1991, Information
technology -- ISO 7-bit coded character set for
information interchange.", 1991.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, the IETF Standards Process", BCP 11, RFC 2028,
October 1996. October 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996. RFC 2047, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234bis]
Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", draft-crocker-abnf-rfc2234bis-00
(work in progress), March 2005.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
10646", RFC 2781, February 2000. 10646", RFC 2781, February 2000.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, June 2000. Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002. Timestamps", RFC 3339, July 2002.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
July 2003. July 2003.
9.2 Informative References [UN_M.49] Statistical Division, United Nations, "Standard Country or
Area Codes for Statistical Use", UN Standard Country or
[initial-registry] Area Codes for Statistical Use, Revision 4 (United Nations
Ewell, D., Ed., "Initial Language Subtag Registry", publication, Sales No. 98.XVII.9, June 1999.
June 2005, <http://www.ietf.org/internet-drafts/
draft-ietf-ltru-initial-registry-00.txt>.
[iso639.principles] 9.2 Informative References
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] [RFC1766] Alvestrand, H., "Tags for the Identification of
Raymond, E., "The Art of Unix Programming", 2003. Languages", RFC 1766, March 1995.
[XML10] Bray (et al), T., "Extensible Markup Language (XML) 1.0", [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
02 2004. Word Extensions: Character Sets, Languages, and
Continuations", RFC 2231, November 1997.
[XMLSchema] [RFC3066] Alvestrand, H., "Tags for the Identification of
Biron, P., Ed. and A. Malhotra, Ed., "XML Schema Part 2: Languages", BCP 47, RFC 3066, January 2001.
Datatypes Second Edition", 10 2004, <
http://www.w3.org/TR/xmlschema-2/>.
[Unicode] Unicode Consortium, "The Unicode Consortium. The Unicode [Unicode] Unicode Consortium, "The Unicode Consortium. The Unicode
Standard, Version 4.1.0, defined by: The Unicode Standard, Standard, Version 4.1.0, defined by: The Unicode Standard,
Version 4.0 (Boston, MA, Addison-Wesley, 2003. ISBN 0-321- Version 4.0 (Boston, MA, Addison-Wesley, 2003. ISBN 0-321-
18578-1), as amended by Unicode 4.0.1 18578-1), as amended by Unicode 4.0.1
(http://www.unicode.org/versions/Unicode4.0.1) and by (http://www.unicode.org/versions/Unicode4.0.1) and by
Unicode 4.1.0 Unicode 4.1.0
(http://www.unicode.org/versions/Unicode4.1.0).", (http://www.unicode.org/versions/Unicode4.1.0).",
March 2005. March 2005.
[RFC1766] Alvestrand, H., "Tags for the Identification of [XML10] Bray (et al), T., "Extensible Markup Language (XML) 1.0",
Languages", RFC 1766, March 1995. 02 2004.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded [XMLSchema]
Word Extensions: Character Sets, Languages, and Biron, P., Ed. and A. Malhotra, Ed., "XML Schema Part 2:
Continuations", RFC 2231, November 1997. Datatypes Second Edition", 10 2004, <
http://www.w3.org/TR/xmlschema-2/>.
[RFC3066] Alvestrand, H., "Tags for the Identification of [initial-registry]
Languages", BCP 47, RFC 3066, January 2001. Ewell, D., Ed., "Initial Language Subtag Registry",
June 2005, <http://www.ietf.org/internet-drafts/
draft-ietf-ltru-initial-registry-00.txt>.
[iso639.principles]
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.
Authors' Addresses Authors' Addresses
Addison Phillips (editor) Addison Phillips (editor)
Quest Software Quest Software
Email: addison.phillips@quest.com Email: addison.phillips@quest.com
URI: http://www.inter-locale.com URI: http://www.inter-locale.com
Mark Davis (editor) Mark Davis (editor)
skipping to change at page 57, line 26 skipping to change at page 58, line 26
The following people (in alphabetical order) contributed to this The following people (in alphabetical order) contributed to this
document or to RFCs 1766 and 3066: document or to RFCs 1766 and 3066:
Glenn Adams, Harald Tveit Alvestrand, Tim Berners-Lee, Marc Blanchet, Glenn Adams, Harald Tveit Alvestrand, Tim Berners-Lee, Marc Blanchet,
Nathaniel Borenstein, Karen Broome, Eric Brunner, Sean M. Burke, M.T. Nathaniel Borenstein, Karen Broome, Eric Brunner, Sean M. Burke, M.T.
Carrasco Benitez, Jeremy Carroll, John Clews, Jim Conklin, Peter Carrasco Benitez, Jeremy Carroll, John Clews, Jim Conklin, Peter
Constable, John Cowan, Mark Crispin, Dave Crocker, Martin Duerst, Constable, John Cowan, Mark Crispin, Dave Crocker, Martin Duerst,
Frank Ellerman, Michael Everson, Doug Ewell, Ned Freed, Tim Goodwin, Frank Ellerman, Michael Everson, Doug Ewell, Ned Freed, Tim Goodwin,
Dirk-Willem van Gulik, Marion Gunn, Joel Halpren, Elliotte Rusty Dirk-Willem van Gulik, Marion Gunn, Joel Halpren, Elliotte Rusty
Harold, Paul Hoffman, Scott Hollenbeck, Richard Ishida, Olle Harold, Paul Hoffman, Scott Hollenbeck, Richard Ishida, Olle
Jarnefors, Kent Karlsson, John Klensin, Alain LaBonte, Eric Mader, Jarnefors, Kent Karlsson, John Klensin, Erkki Kolehmainen, Alain
Ira McDonald, Keith Moore, Chris Newman, Masataka Ohta, Dylan Pierce, LaBonte, Eric Mader, Ira McDonald, Keith Moore, Chris Newman,
Randy Presuhn, George Rhoten, Markus Scherer, Keld Jorn Simonsen, Masataka Ohta, Dylan Pierce, Randy Presuhn, George Rhoten, Felix
Thierry Sourbier, Otto Stolz, Tex Texin, Andrea Vine, Rhys Sasaki, Markus Scherer, Keld Jorn Simonsen, Thierry Sourbier, Otto
Weatherley, Misha Wolf, Francois Yergeau and many, many others. Stolz, Tex Texin, Andrea Vine, Rhys Weatherley, Misha Wolf, Francois
Yergeau and many, many others.
Very special thanks must go to Harald Tveit Alvestrand, who Very special thanks must go to Harald Tveit Alvestrand, who
originated RFCs 1766 and 3066, and without whom this document would originated RFCs 1766 and 3066, and without whom this document would
not have been possible. Special thanks must go to Michael Everson, not have been possible. Special thanks must go to Michael Everson,
who has served as language tag reviewer for almost the complete who has served as language tag reviewer for almost the complete
period since the publication of RFC 1766. Special thanks to Doug period since the publication of RFC 1766. Special thanks to Doug
Ewell, for his production of the first complete subtag registry, and Ewell, for his production of the first complete subtag registry, and
his work in producing a test parser for verifying language tags. his work in producing a test parser for verifying language tags.
Appendix B. Examples of Language Tags (Informative) Appendix B. Examples of Language Tags (Informative)
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/