draft-ietf-ltru-registry-04.txt   draft-ietf-ltru-registry-05.txt 
Network Working Group A. Phillips, Ed. Network Working Group A. Phillips, Ed.
Internet-Draft Quest Software Internet-Draft Quest Software
Expires: December 5, 2005 M. Davis, Ed. Expires: December 17, 2005 M. Davis, Ed.
IBM IBM
June 03, 2005 June 15, 2005
Tags for Identifying Languages Tags for Identifying Languages
draft-ietf-ltru-registry-04 draft-ietf-ltru-registry-05
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 December 5, 2005. This Internet-Draft will expire on December 17, 2005.
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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
2. The Language Tag . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Language Tag . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Length Considerations . . . . . . . . . . . . . . . . 6 2.1.1 Length Considerations . . . . . . . . . . . . . . . . 6
2.2 Language Subtag Sources and Interpretation . . . . . . . . 8 2.2 Language Subtag Sources and Interpretation . . . . . . . . 8
2.2.1 Primary Language Subtag . . . . . . . . . . . . . . . 9 2.2.1 Primary Language Subtag . . . . . . . . . . . . . . . 9
2.2.2 Extended Language Subtags . . . . . . . . . . . . . . 11 2.2.2 Extended Language Subtags . . . . . . . . . . . . . . 11
2.2.3 Script Subtag . . . . . . . . . . . . . . . . . . . . 12 2.2.3 Script Subtag . . . . . . . . . . . . . . . . . . . . 12
2.2.4 Region Subtag . . . . . . . . . . . . . . . . . . . . 13 2.2.4 Region Subtag . . . . . . . . . . . . . . . . . . . . 13
2.2.5 Variant Subtags . . . . . . . . . . . . . . . . . . . 14 2.2.5 Variant Subtags . . . . . . . . . . . . . . . . . . . 14
2.2.6 Extension Subtags . . . . . . . . . . . . . . . . . . 15 2.2.6 Extension Subtags . . . . . . . . . . . . . . . . . . 15
2.2.7 Private Use Subtags . . . . . . . . . . . . . . . . . 16 2.2.7 Private Use Subtags . . . . . . . . . . . . . . . . . 17
2.2.8 Pre-Existing RFC 3066 Registrations . . . . . . . . . 17 2.2.8 Pre-Existing RFC 3066 Registrations . . . . . . . . . 17
2.2.9 Classes of Conformance . . . . . . . . . . . . . . . . 17 2.2.9 Classes of Conformance . . . . . . . . . . . . . . . . 17
3. Registry Format and Maintenance . . . . . . . . . . . . . . . 19 3. Registry Format and Maintenance . . . . . . . . . . . . . . . 19
3.1 Format of the IANA Language Subtag Registry . . . . . . . 19 3.1 Format of the IANA Language Subtag Registry . . . . . . . 19
3.2 Maintenance of the Registry . . . . . . . . . . . . . . . 24 3.2 Maintenance of the Registry . . . . . . . . . . . . . . . 24
3.3 Stability of IANA Registry Entries . . . . . . . . . . . . 25 3.3 Stability of IANA Registry Entries . . . . . . . . . . . . 25
3.4 Registration Procedure for Subtags . . . . . . . . . . . . 28 3.4 Registration Procedure for Subtags . . . . . . . . . . . . 29
3.5 Possibilities for Registration . . . . . . . . . . . . . . 31 3.5 Possibilities for Registration . . . . . . . . . . . . . . 32
3.6 Extensions and Extensions Namespace . . . . . . . . . . . 33 3.6 Extensions and Extensions Namespace . . . . . . . . . . . 33
3.7 Initialization of the Registry . . . . . . . . . . . . . . 36 3.7 Initialization of the Registry . . . . . . . . . . . . . . 36
4. Formation and Processing of Language Tags . . . . . . . . . . 39 4. Formation and Processing of Language Tags . . . . . . . . . . 39
4.1 Choice of Language Tag . . . . . . . . . . . . . . . . . . 39 4.1 Choice of Language Tag . . . . . . . . . . . . . . . . . . 39
4.2 Meaning of the Language Tag . . . . . . . . . . . . . . . 41 4.2 Meaning of the Language Tag . . . . . . . . . . . . . . . 41
4.3 Canonicalization of Language Tags . . . . . . . . . . . . 42 4.3 Canonicalization of Language Tags . . . . . . . . . . . . 42
4.4 Considerations for Private Use Subtags . . . . . . . . . . 44 4.4 Considerations for Private Use Subtags . . . . . . . . . . 44
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
6. Security Considerations . . . . . . . . . . . . . . . . . . . 46 6. Security Considerations . . . . . . . . . . . . . . . . . . . 46
7. Character Set Considerations . . . . . . . . . . . . . . . . . 47 7. Character Set Considerations . . . . . . . . . . . . . . . . . 47
8. Changes from RFC 3066 . . . . . . . . . . . . . . . . . . . . 48 8. Changes from RFC 3066 . . . . . . . . . . . . . . . . . . . . 48
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
9.1 Normative References . . . . . . . . . . . . . . . . . . . 52 9.1 Normative References . . . . . . . . . . . . . . . . . . . 51
9.2 Informative References . . . . . . . . . . . . . . . . . . 53 9.2 Informative References . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 53
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54
B. Examples of Language Tags (Informative) . . . . . . . . . . . 56 B. Examples of Language Tags (Informative) . . . . . . . . . . . 55
C. Example Registry . . . . . . . . . . . . . . . . . . . . . . . 59 C. Example Registry . . . . . . . . . . . . . . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . . . . . . . 63 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.
Information about a user's language preferences commonly needs to be Information about a user's language preferences commonly needs to be
identified so that appropriate processing can be applied. For identified so that appropriate processing can be applied. For
example, the user's language preferences in a browser can be used to example, the user's language preferences in a browser can be used to
skipping to change at page 3, line 47 skipping to change at page 3, line 47
This document specifies an identifier mechanism and a registration This document specifies an identifier mechanism and a registration
function for values to be used with that identifier mechanism. It function for values to be used with that identifier mechanism. It
also defines a mechanism for private use values and future extension. also defines a mechanism for private use values and future extension.
This document replaces RFC 3066, which replaced RFC 1766. For a list This document replaces RFC 3066, which replaced RFC 1766. For a list
of changes in this document, see Section 8. 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 RFC 2119 [10]. document are to be interpreted as described in RFC 2119 [11].
2. The Language Tag 2. The Language Tag
2.1 Syntax 2.1 Syntax
The language tag is composed of one or more parts: A primary language The language tag is composed of one or more parts: A primary language
subtag and a (possibly empty) series of subsequent subtags. Subtags subtag and a (possibly empty) series of subsequent subtags. Subtags
are distinguished by their length, position in the subtag sequence, are distinguished by their length, position in the subtag sequence,
and content, so that each type of subtag can be recognized solely by and content, so that each type of subtag can be recognized solely by
these features. This makes it possible to construct a parser that these features. This makes it possible to construct a parser that
skipping to change at page 6, line 4 skipping to change at page 6, line 4
five characters long. five characters long.
Whitespace is not permitted in a language tag. For examples of Whitespace is not permitted in a language tag. For examples of
language tags, see Appendix B. language tags, see Appendix B.
Note that although [7] refers to octets, the language tags described Note that although [7] refers to octets, the language tags described
in this document are sequences of characters from the US-ASCII in this document are sequences of characters from the US-ASCII
repertoire. Language tags MAY be used in documents and applications repertoire. Language tags MAY be used in documents and applications
that use other encodings, so long as these encompass the US-ASCII that use other encodings, so long as these encompass the US-ASCII
repertoire. An example of this would be an XML document that uses repertoire. An example of this would be an XML document that uses
the UTF-16LE [12] encoding of Unicode [21]. the UTF-16LE [13] encoding of Unicode [21].
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 [ISO 639] [1] recommends that language codes be written in lower o [ISO 639] [1] recommends that language codes be written in lower
case ('mn' Mongolian). case ('mn' Mongolian).
skipping to change at page 6, line 36 skipping to change at page 6, line 36
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
variations conveys the same meaning: Mongolian written in the variations conveys the same meaning: Mongolian written in the
Cyrillic script as used in Mongolia. Cyrillic script as used in Mongolia.
2.1.1 Length Considerations 2.1.1 Length Considerations
RFC 3066 [24] did not provide an upper limit on the size of language RFC 3066 [24] did not provide an upper limit on the size of language
tags. While RFC 3066 did define the semantics of particular subtags tags. While RFC 3066 did define the semantics of particular subtags
in such a way that most language tags consisted of language and in such a way that most language tags consisted of language and
region subtags with a combined total length of up to six characters, region subtags with a combined total length of up to six characters,
much larger registered tags were not only possible but were actually larger registered tags were not only possible but were actually
registered. registered.
Neither this document nor the syntax in the ANBF imposes a fixed Neither this document nor the syntax in the ANBF imposes a fixed
upper limit on the number of subtags in a language tag (and thus an upper limit on the number of subtags in a language tag (and thus an
upper bound on the size of a tag). The syntax in this document upper bound on the size of a tag). The syntax in this document
suggests that, depending on the specific language, more subtags (and suggests that, depending on the specific language, more subtags (and
thus characters) are sometimes necessary to form a complete tag; thus thus characters) are sometimes necessary to form a complete tag; thus
it is possible to envision long or complex subtag sequences. it is possible to envision long or complex subtag sequences.
Some applications and protocols are forced to allocate fixed buffer Some applications and protocols are forced to allocate fixed buffer
skipping to change at page 7, line 34 skipping to change at page 7, line 34
If truncation is permitted it MUST NOT permit a subtag to be divided If truncation is permitted it MUST NOT permit a subtag to be divided
or the formation of invalid tags (for example, one ending with the or the formation of invalid tags (for example, one ending with the
"-" character). A protocol that allows tags to be truncated at an "-" character). A protocol that allows tags to be truncated at an
arbitrary limit, without giving any indication of what that limit is, arbitrary limit, without giving any indication of what that limit is,
has the potential for causing harm by changing the meaning of tags in has the potential for causing harm by changing the meaning of tags in
substantial ways. substantial ways.
Some specifications are space constrained but do not have a fixed Some specifications are space constrained but do not have a fixed
length limitation. For example, see [RFC 2231] [23]. This protocol length limitation. For example, see [RFC 2231] [23]. This protocol
has no explicit length limitation: the language tag's length is has no explicit length limitation: the length of the language tag in
limited by the length of other header components (such as the this document is limited by the length of other header components
charset's name) coupled with the 78 character limit in [RFC 2822] (such as the charset's name) coupled with the 76 character limit in
[14]. Thus the "limit" might be 60 or more characters, but it could [RFC 2047] [10]. Thus the "limit" might be 50 or more characters,
potentially be quite small. In these cases, implementations SHOULD but it could potentially be quite small. In these cases,
use the longest possible language tag. Warning the user of implementations SHOULD use the longest possible language tag.
truncation, if necessary, is RECOMMENDED, as truncation can change Warning the user of truncation, if necessary, is RECOMMENDED, as
the semantic meaning of the tag. truncation can change the semantic meaning of the tag.
The following illustration shows how the 42-character recommendation The following illustration shows how the 42-character recommendation
was derived. The combination of language and extended language was derived. The combination of language and extended language
subtags was chosen for future compatibility. At up to 11 characters, subtags was chosen for future compatibility. At up to 11 characters,
this combination is longer than the longest possible language subtag this combination is longer than the longest possible language subtag
(8 characters): (8 characters):
language = 3 (ISO 639-2; ISO 639-1 requires 2) language = 3 (ISO 639-2; ISO 639-1 requires 2)
extlang1 = 4 (each subsequent subtag includes '-') extlang1 = 4 (each subsequent subtag includes '-')
extlang2 = 4 (unlikely: needs prefix="language-extlang1") extlang2 = 4 (unlikely: needs prefix="language-extlang1")
skipping to change at page 8, line 38 skipping to change at page 8, line 38
3. zh-Hant-CN-variant1 3. zh-Hant-CN-variant1
4. zh-Hant-CN 4. zh-Hant-CN
5. zh-Hant 5. zh-Hant
6. zh 6. zh
Figure 3: Example of Tag Truncation Figure 3: Example of Tag Truncation
2.2 Language Subtag Sources and Interpretation 2.2 Language Subtag Sources and Interpretation
The namespace of language tags and their subtags is administered by The namespace of language tags and their subtags is administered by
the Internet Assigned Numbers Authority (IANA) [13] according to the the Internet Assigned Numbers Authority (IANA) [14] according to the
rules in Section 5 of this document. The registry maintained by IANA rules in Section 5 of this document. The registry maintained by IANA
is the source for valid subtags: other standards referenced in this is the source for valid subtags: other standards referenced in this
section provide the source material for that registry. section provide the source material for that registry.
Terminology in this section: Terminology in this section:
o Tag or tags refers to a complete language tag, such as o Tag or tags refers to a complete language tag, such as
"fr-Latn-CA". Examples of tags in this document are enclosed in "fr-Latn-CA". Examples of tags in this document are enclosed in
double-quotes ("en-US"). double-quotes ("en-US").
skipping to change at page 13, line 6 skipping to change at page 13, line 6
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.4 for more registered script values. Please refer to Section 4.4 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 cannot 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.
Example: "de-Latn" represents German written using the Latin script. 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
value to the tag or when the primary language subtag's record
includes a Supress-Script field listing the applicable script
subtag.
Example: "sr-Latn" represents Serbian written using the Latin script.
2.2.4 Region Subtag 2.2.4 Region Subtag
The following rules apply to the region subtags: The following rules apply to the region subtags:
1. The region subtag defines language variations used in a specific 1. The region subtag defines language variations used in a specific
region, geographic, or political area. Region subtags MUST region, geographic, or political area. Region subtags MUST
follow any language, extended language, or script subtags and follow any language, extended language, or script subtags and
MUST precede all other subtags. 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 ISO 3166 [4]--"Codes for the representation of names of in ISO 3166 [4]--"Codes for the representation of names of
countries and their subdivisions - Part 1: Country countries and their subdivisions - Part 1: Country
codes"--alpha-2 country codes or assignments subsequently made by codes"--alpha-2 country codes or assignments subsequently made by
the ISO 3166 maintenance agency or governing standardization the ISO 3166 maintenance agency or governing standardization
bodies. bodies.
3. All three character codes consisting of digit (numeric) 3. All three character subtags consisting of digit (numeric)
characters were defined in the IANA registry according to the characters following the primary subtag were defined in the IANA
assignments found in UN Standard Country or Area Codes for registry according to the assignments found in UN Standard
Statistical Use [5] or assignments subsequently made by the Country or Area Codes for Statistical Use [5] (UN M.49) or
governing standards body. Note that not all of the UN M.49 codes assignments subsequently made by the governing standards body.
are defined in the IANA registry: Note that not all of the UN M.49 codes are defined in the IANA
registry. The following rules define which codes are entered
into the registry as valid subtags:
A. UN numeric codes assigned to 'macro-geographical A. UN numeric codes assigned to 'macro-geographical
(continental)' or sub-regions not associated with an assigned (continental)' or sub-regions MUST be registered in the
ISO 3166 alpha-2 code _are_ defined. registry. These codes are not associated with an assigned
ISO 3166 alpha-2 code and represent supra-national areas,
usually covering more than one nation, state, province, or
territory.
B. UN numeric codes for 'economic groupings' or 'other B. UN numeric codes for 'economic groupings' or 'other
groupings' are _not_ defined in the IANA registry and MUST groupings' MUST NOT be registered in the IANA registry and
NOT be used to form language tags. MUST NOT be used to form language tags.
C. UN numeric codes for countries with ambiguous ISO 3166 C. UN numeric codes for countries or areas with ambiguous ISO
alpha-2 codes as defined in Section 3.3 are defined in the 3166 alpha-2 codes, when entered into the registry, MUST be
registry and are canonical for the given country or region defined according to the rules in Section 3.3 and MUST be
defined. used to form language tags that represent the country or
region for which they are defined.
D. The alphanumeric codes in Appendix X of the UN document are D. UN numeric codes for countries or areas for which there is an
_not_ defined and MUST NOT be used to form language tags. associated ISO 3166 alpha-2 code in the registry MUST NOT be
(At the time this document was created these values match the entered into the registry and MUST NOT be used to form
ISO 3166 alpha-2 codes.) language tags. Note that the ISO 3166-based subtag in the
4. There MUST be at most one region subtag in a language tag. registry MUST actually be associated with the UN M.49 code in
question.
5. The region subtags 'AA', 'QM'-'QZ', 'XA'-'XZ', and 'ZZ' are E. All other UN numeric codes for countries or areas which do
not have an associated ISO 3166 alpha-2 code MUST NOT be
entered into the registry and MUST NOT be used to form
language tags. For more information about these codes, see
Section 3.3.
4. Note: The alphanumeric codes in Appendix X of the UN document
MUST NOT be entered into the registry and MUST NOT be used to
form language tags. (At the time this document was created these
values match the ISO 3166 alpha-2 codes.)
5. There MUST be at most one region subtag in a language tag and the
region subtag MAY be omitted, as when it adds no distinguishing
value to the tag.
6. The region subtags 'AA', 'QM'-'QZ', 'XA'-'XZ', and 'ZZ' are
reserved for private use in language tags. These subtags reserved for private use in language tags. These subtags
correspond to codes reserved by ISO 3166 for private use. These correspond to codes reserved by ISO 3166 for private use. These
codes MAY be used for private use region subtags (instead of codes MAY be used for private use region subtags (instead of
using a private-use subtag sequence). Please refer to using a private-use subtag sequence). Please refer to
Section 4.4 for more information on private use subtags. Section 4.4 for more information on private use subtags.
"de-CH" represents German ('de') as used in Switzerland ('CH'). "de-CH" represents German ('de') as used in Switzerland ('CH').
"sr-Latn-CS" represents Serbian ('sr') written using Latin script "sr-Latn-CS" represents Serbian ('sr') written using Latin script
('Latn') as used in Serbia and Montenegro ('CS'). ('Latn') as used in Serbia and Montenegro ('CS').
skipping to change at page 15, line 12 skipping to change at page 15, line 40
example, the subtag 'scouse' has a Prefix of "en", making it suitable example, the subtag 'scouse' has a Prefix of "en", making it suitable
to form language tags such as "en-scouse" and "en-GB-scouse", but not to form language tags such as "en-scouse" and "en-GB-scouse", but not
suitable for use in a tag such as "zh-scouse" or "it-GB-scouse". suitable for use in a tag such as "zh-scouse" or "it-GB-scouse".
"en-scouse" represents the Scouse dialect of English. "en-scouse" represents the Scouse dialect of English.
"de-CH-1996" represents German as used in Switzerland and as written "de-CH-1996" represents German as used in Switzerland and as written
using the spelling reform beginning in the year 1996 C.E. using the spelling reform beginning in the year 1996 C.E.
Most variants that share a prefix are mutually exclusive. For Most variants that share a prefix are mutually exclusive. For
example, the German orthographic variantions '1996' and '1901' SHOULD example, the German orthographic variations '1996' and '1901' SHOULD
NOT be used in the same tag, as they represent the dates of different NOT be used in the same tag, as they represent the dates of different
spelling reforms. A variant that can meaningfully be used in spelling reforms. A variant that can meaningfully be used in
combination with another variant SHOULD include a 'Prefix' field in combination with another variant SHOULD include a 'Prefix' field in
its registry record that lists that other variant. For example, if its registry record that lists that other variant. For example, if
another German variant 'example' were created that made sense to use another German variant 'example' were created that made sense to use
with '1996', then 'example' should include two Prefix fields: "de" with '1996', then 'example' should include two Prefix fields: "de"
and "de-1996". and "de-1996".
2.2.6 Extension Subtags 2.2.6 Extension Subtags
skipping to change at page 23, line 10 skipping to change at page 23, line 10
Thie field 'Preferred-Value' contains a mapping between the record in Thie field 'Preferred-Value' contains a mapping between the record in
which it appears and a tag or subtag which SHOULD be preferred when which it appears and a tag or subtag which SHOULD be preferred when
selected language tags. These values form three groups: selected language tags. These values form three groups:
ISO 639 language codes which were later withdrawn in favor of ISO 639 language codes which were later withdrawn in favor of
other codes. These values are mostly a historical curiosity. other codes. These values are mostly a historical curiosity.
ISO 3166 region codes which have been withdrawn in favor of a new ISO 3166 region codes which have been withdrawn in favor of a new
code. This sometimes happens when a country changes its name or code. This sometimes happens when a country changes its name or
administration in such a way that warrents a new region code. administration in such a way that warrants a new region code.
Tags grandfathered from RFC 3066. In many cases these tags have Tags grandfathered from RFC 3066. In many cases these tags have
become obsolete because the values they represent were later become obsolete because the values they represent were later
encoded by ISO 639. encoded by ISO 639.
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
skipping to change at page 24, line 39 skipping to change at page 24, line 39
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".
For examples of registry entries and their format, see Appendix C. For examples of registry entries and their format, see Appendix C.
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, and ISO 3166, the Language Subtag withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language
Reviewer will evaluate each change, determine whether it conflicts Subtag Reviewer will evaluate each change, determine whether it
with existing registry entries, and submit the information to IANA conflicts with existing registry entries, and submit the information
for inclusion in the registry. If an change takes place and the to IANA for inclusion in the registry. If an change takes place and
Language Subtag Reviewer does not do this in a timely manner, then the Language Subtag Reviewer does not do this in a timely manner,
any interested party MAY use the procedure in Section 3.4 to register then any interested party MAY use the procedure in Section 3.4 to
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 RFC 3066 [24]. The redundant complete list of tags registered under RFC 3066 [24]. The redundant
tags are those that can now be formed using the subtags defined in tags are those that can now be formed using the subtags defined in
the registry together with the rules of Section 2.2. The the registry together with the rules of Section 2.2. The
grandfathered entries are those that can never be legal under those grandfathered entries are those that can never be legal under those
same provisions. same provisions.
The set of redundant and grandfathered tags is permanent and stable: The set of redundant and grandfathered tags is permanent and stable:
no new entries will be added and none of the entries will be removed. no new entries will be added and none of the entries will be removed.
skipping to change at page 26, line 47 skipping to change at page 26, line 47
o The field 'Comments' MAY be added, changed, modified, or removed o The field 'Comments' MAY be added, changed, modified, or removed
via the registration process or any of the processes or via the registration process or any of the processes or
considerations described in this section. considerations described in this section.
o The field 'Suppress-Script' MAY be added or removed via the o The field 'Suppress-Script' MAY be added or removed via the
registration process. registration process.
o Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do not o Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do not
conflict with existing subtags of the associated type and whose conflict with existing subtags of the associated type and whose
meaning is not the same as an existing subtag of the same type are meaning is not the same as an existing subtag of the same type are
entered into the IANA registry as new records and their value is entered into the IANA registry as new records.
canonical for the meaning assigned to them.
o Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are o 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 withdrawl is added to the record. If a new containing the date of withdrawal is added to the record. If a
record of the same type is added that represents a replacement new record of the same type is added that represents a replacement
value, then a 'Preferred-Value' field MAY also be added. The value, then a 'Preferred-Value' field MAY also be added. The
registration process MAY be used to add comments about the registration process MAY be used to add comments about the
withdrawal of the code by the respective standard. withdrawal of the code by the respective standard.
* The region code 'TL' was assigned to the country 'Timor-Leste', * The region code 'TL' was assigned to the country 'Timor-Leste',
replacing the code 'TP' (which was assigned to 'East Timor' replacing the code 'TP' (which was assigned to 'East Timor'
when it was under administration by Portugal). The subtag 'TP' when it was under administration by Portugal). The subtag 'TP'
remains valid in language tags, but its record contains the a remains valid in language tags, but its record contains the a
'Preferred-Value' of 'TL' and its field 'Deprecated' contains 'Preferred-Value' of 'TL' and its field 'Deprecated' contains
the date the new code was assigned ('2004-07-06'). the date the new code was assigned ('2004-07-06').
o Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict o 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
following additional considerations apply: following additional considerations apply to subtag values that
are reassigned:
* For ISO 639 codes, if the newly assigned code's meaning is not * For ISO 639 codes, if the newly assigned code's meaning is not
represented by a subtag in the IANA registry, the Language represented by a subtag in the IANA registry, the Language
Subtag Reviewer, as described in Section 3.4, SHALL prepare a Subtag Reviewer, as described in Section 3.4, SHALL prepare a
proposal for entering in the IANA registry as soon as practical proposal for entering in the IANA registry as soon as practical
a registered language subtag as an alternate value for the new a registered language subtag as an alternate value for the new
code. The form of the registered language subtag will be at code. The form of the registered language subtag will be at
the discretion of the Language Subtag Reviewer and MUST conform the discretion of the Language Subtag Reviewer and MUST conform
to other restrictions on language subtags in this document. to other restrictions on language subtags in this document.
skipping to change at page 28, line 14 skipping to change at page 28, line 14
* For ISO 3166 codes, if the newly assigned code's meaning is * For ISO 3166 codes, if the newly assigned code's meaning is
associated with the same UN M.49 code as another 'region' associated with the same UN M.49 code as another 'region'
subtag, then the existing region subtag remains as the subtag, then the existing region subtag remains as the
preferred value for that region and no new entry is created. A preferred value for that region and no new entry is created. A
comment MAY be added to the existing region subtag indicating comment MAY be added to the existing region subtag indicating
the relationship to the new ISO 3166 code. the relationship to the new ISO 3166 code.
* For ISO 3166 codes, if the newly assigned code's meaning is * For ISO 3166 codes, if the newly assigned code's meaning is
associated with a UN M.49 code that is not represented by an associated with a UN M.49 code that is not represented by an
existing region subtag, then then the Language Subtag Reviewer, existing region subtag, then the Language Subtag Reviewer, as
as described in Section 3.4, SHALL prepare a proposal for described in Section 3.4, SHALL prepare a proposal for entering
entering the appropriate numeric UN country code as an entry in the appropriate UN M.49 country code as an entry in the IANA
the IANA registry. registry.
* Codes assigned by UN M.49 to countries or areas (as opposed to
geographical regions and sub-regions) for which there is no
corresponding ISO 3166 code MUST NOT be registered, except
under the previous provision. If it is necessary to identify a
region for which only a UN M.49 code exists in language tags,
then the registration authority for ISO 3166 SHOULD be
petitioned to assign a code, which can then be registered for
use in language tags. At the time this document was written,
there were only four such codes: 830 (Channel Islands), 831
(Guernsey), 832 (Jersey), and 833 (Isle of Man). This rule
exists so that UN M.49 codes remain available as the value of
last resort in cases where ISO 3166 reassigns a deprecated
value in the registry.
* For ISO 3166 codes, if there is no associated UN numeric code, * For ISO 3166 codes, if there is no associated UN numeric code,
then the Language Subtag Reviewer SHALL petition the UN to then the Language Subtag Reviewer SHALL petition the UN to
create one. If there is no response from the UN within ninety create one. If there is no response from the UN within ninety
days of the request being sent, the Language Subtag Reviewer days of the request being sent, the Language Subtag Reviewer
SHALL prepare a proposal for entering in the IANA registry as SHALL prepare a proposal for entering in the IANA registry as
soon as practical a registered variant subtag as an alternate soon as practical a registered variant subtag as an alternate
value for the new code. The form of the registered variant value for the new code. The form of the registered variant
subtag will be at the discretion of the Language Subtag subtag will be at the discretion of the Language Subtag
Reviewer and MUST conform to other restrictions on variant Reviewer and MUST conform to other restrictions on variant
skipping to change at page 29, line 13 skipping to change at page 29, line 26
with ISO 639, ISO 15924, ISO 3166, and UN M.49 within the limits with ISO 639, ISO 15924, ISO 3166, and UN M.49 within the limits
defined by this document are described in Section 3.2. Stability defined by this document are described in Section 3.2. Stability
provisions are described in Section 3.3. provisions are described in Section 3.3.
This procedure MAY also be used to register or alter the information This procedure MAY also be used to register or alter the information
for the "Description", "Comments", "Deprecated", or "Prefix" fields for the "Description", "Comments", "Deprecated", or "Prefix" fields
in a subtag's record as described in Figure 9. Changes to all other in a subtag's record as described in Figure 9. Changes to all other
fields in the IANA registry are NOT permitted. fields in the IANA registry are NOT permitted.
Registering a new subtag or requesting modifications to an existing Registering a new subtag or requesting modifications to an existing
tag or subtag starts with the requster filling out the registration tag or subtag starts with the requester filling out the registration
form reproduced below. Note that each response is not limited in form reproduced below. Note that each response is not limited in
size so that the request can adequately describe the registration. size so that the request can adequately describe the registration.
The fields in the "Record Requested" section SHOULD follow the The fields in the "Record Requested" section SHOULD follow the
requirements in Section 3.1. requirements in Section 3.1.
LANGUAGE SUBTAG REGISTRATION FORM LANGUAGE SUBTAG REGISTRATION FORM
1. Name of requester: 1. Name of requester:
2. E-mail address of requester: 2. E-mail address of requester:
3. Record Requested: 3. Record Requested:
skipping to change at page 32, line 23 skipping to change at page 32, line 39
'scouse' subtag (the Scouse dialect of English). 'scouse' subtag (the Scouse dialect of English).
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
Section 3.3. This includes descriptions; comments; deprecation Section 3.3. This includes descriptions; comments; deprecation
and preferred values for obsolete or withdrawn codes; or the and preferred values for obsolete or withdrawn codes; or the
addition of script or extlang information to primary language addition of script or extlang information to primary language
subtags. subtags.
o The addition of records and related field value changes necessary
to reflect assignments made by ISO 639, ISO 15924, ISO 3166, and
UN M.49 as described in Section 3.3.
This document leaves the decision on what subtags or changes to This document leaves the decision on what subtags or changes to
subtags are appropriate (or not) to the registration process subtags are appropriate (or not) to the registration process
described in Section 3.4. described in Section 3.4.
Note: four character primary language subtags are reserved to allow Note: four character primary language subtags are reserved to allow
for the possibility of alpha4 codes in some future addition to the for the possibility of alpha4 codes in some future addition to the
ISO 639 family of standards. ISO 639 family of standards.
ISO 639 defines a maintenance agency for additions to and changes in ISO 639 defines a maintenance agency for additions to and changes in
the list of languages in ISO 639. This agency is: the list of languages in ISO 639. This agency is:
skipping to change at page 37, line 21 skipping to change at page 37, line 38
deprecated. The 'Comments' field will contain the reason for the deprecated. The 'Comments' field will contain the reason for the
deprecation. The 'Preferred-Value' field will contain the tag that deprecation. The 'Preferred-Value' field will contain the tag that
replaces the value. For example, the tag "art-lojban" is deprecated replaces the value. For example, the tag "art-lojban" is deprecated
and will be placed in the grandfathered section. It's 'Deprecated' and will be placed in the grandfathered section. It's 'Deprecated'
field will contain the deprecation date (in this case "2003-09-02") field will contain the deprecation date (in this case "2003-09-02")
and the 'Preferred-Value' field the value "jbo". and the 'Preferred-Value' field the value "jbo".
Tags that are not deprecated and which contain subtags which are Tags that are not deprecated and which contain subtags which are
consistent with registration under the guidelines in this document consistent with registration under the guidelines in this document
will not automatically have a new subtag registration created for will not automatically have a new subtag registration created for
each eligible subtag. Interrested parties MAY use the registration each eligible subtag. Interested parties MAY use the registration
process in Section 3.4 to register these subtags. If all of the process in Section 3.4 to register these subtags. If all of the
subtags in the original tag become fully defined by the resulting subtags in the original tag become fully defined by the resulting
registrations, then the original tag is superseded by this document. registrations, then the original tag is superseded by this document.
Such tags will have their record changed from type 'grandfathered' to Such tags will have their record changed from type 'grandfathered' to
type 'redundant' in the registry. For example, the subtag 'boont' type 'redundant' in the registry. For example, the subtag 'boont'
could be registered, resulting in the change of the grandfathered tag could be registered, resulting in the change of the grandfathered tag
"en-boont" to type redundant in the registry. "en-boont" to type redundant in the registry.
Tags that contain one or more subtags that do not match the valid Tags that contain one or more subtags that do not match the valid
registration pattern and which are not otherwise defined by this registration pattern and which are not otherwise defined by this
document will have records of type 'grandfathered' created in the document will have records of type 'grandfathered' created in the
registry. These records cannot become type 'redundant', but MAY have registry. These records cannot become type 'redundant', but MAY have
a 'Deprecated' and 'Prefered-Value' field added to them if a subtag a 'Deprecated' and 'Preferred-Value' field added to them if a subtag
assignment or combination of assignments renders the tag obsolete. assignment or combination of assignments renders the tag obsolete.
There MUST be a reasonable period in which the community can comment There MUST be a reasonable period in which the community can comment
on the proposed list entries, which SHALL be no less than four weeks on the proposed list entries, which SHALL be no less than four weeks
in length. At the completion of this period, the chair(s) will in length. At the completion of this period, the chair(s) will
notify iana@iana.org and the ltru and ietf-languages mail lists that notify iana@iana.org and the ltru and ietf-languages mail lists that
the task is complete and forward the necessary materials to IANA for the task is complete and forward the necessary materials to IANA for
publication. publication.
Registrations that are in process under the rules defined in RFC 3066 Registrations that are in process under the rules defined in RFC 3066
skipping to change at page 38, line 9 skipping to change at page 38, line 24
language tag reviewer. Any new registrations submitted after the language tag reviewer. Any new registrations submitted after the
request for conversion of the registry MUST be rejected. request for conversion of the registry MUST be rejected.
All existing RFC 3066 language tag registrations will be maintained All existing RFC 3066 language tag registrations will be maintained
in perpetuity. in perpetuity.
Users of tags that are grandfathered SHOULD consider registering Users of tags that are grandfathered SHOULD consider registering
appropriate subtags in the IANA subtag registry (but are NOT REQUIRED appropriate subtags in the IANA subtag registry (but are NOT REQUIRED
to). to).
UN numeric codes assigned to 'macro-geographical (continental)' or UN numeric codes assigned to 'macro-geographical (continental)' MUST
sub-regions not associated with an assigned ISO 3166 alpha-2 code are be defined in the IANA registry and made valid for use in language
defined in the IANA registry and are valid for use in language tags. tags. These codes MUST be added to the initial version of the
These codes MUST be added to the initial version of the registry. registry. The UN numeric codes for 'economic groupings' or 'other
The UN numeric codes for 'economic groupings' or 'other groupings', groupings', and the alphanumeric codes in Appendix X of the UN
and the alphanumeric codes in Appendix X of the UN document MUST NOT document MUST NOT be added to the registry. The UN numeric codes for
be added to the registry. countries or areas not associated with an assigned ISO 3166 alpha-2
code MUST NOT be added to the initial version of the registry. These
values MAY be registered by individuals using the process defined in
Section 3.4 and according to the rules in Section 3.3.
When creating records for ISO 639, ISO 15924, ISO3166, and UN M.49 When creating records for ISO 639, ISO 15924, ISO3166, and UN M.49
codes, the following criteria SHALL be applied to the inclusion, codes, the following criteria SHALL be applied to the inclusion,
preferred value, and deprecation of codes: preferred value, and deprecation of codes:
For each standard, the date of the standard referenced in RFC 1766 is For each standard, the date of the standard referenced in RFC 1766 is
selected as the starting date. Codes that were valid on that date in selected as the starting date. Codes that were valid on that date in
the selected standard are added to the registry. Codes that were the selected standard are added to the registry. Codes that were
previously assigned by but which were vacated or withdrawn before previously assigned by but which were vacated or withdrawn before
that date are not added to the registry. For each successive change that date are not added to the registry. For each successive change
skipping to change at page 45, line 8 skipping to change at page 45, line 8
However, in some cases content tagged with private use subtags MAY However, in some cases content tagged with private use subtags MAY
interact with other systems in a different and possibly unsuitable interact with other systems in a different and possibly unsuitable
manner compared to tags that use opaque, privately defined subtags, manner compared to tags that use opaque, privately defined subtags,
so the choice of the best approach sometimes depends on the so the choice of the best approach sometimes depends on the
particular domain in question. particular domain in question.
5. IANA Considerations 5. IANA Considerations
This section deals with the processes and requirements necessary for This section deals with the processes and requirements necessary for
IANA to undertake to maintain the rsubtag and extension registries as IANA to undertake to maintain the subtag and extension registries as
defined by this document and in accordance with the requirements of defined by this document and in accordance with the requirements of
RFC 2434 [11]. RFC 2434 [12].
The impact on the IANA maintainers of the two registries defined by The impact on the IANA maintainers of the two registries defined by
this document will be a small increase in the frequency of new this document will be a small increase in the frequency of new
entries or updates. entries or updates.
Upon adoption of this document, the process described in Section 3.7 Upon adoption of this document, the process described in Section 3.7
will be used to generate the initial Language Subtag Registry. The will be used to generate the initial Language Subtag Registry. The
initial set of records represents no impact on IANA, since the work initial set of records represents no impact on IANA, since the work
to create it will be performed externally (as defined in that to create it will be performed externally (as defined in that
section). The new registry will be listed under "Language Tags" at section). The new registry will be listed under "Language Tags" at
<http://www.iana.org/numbers.html>. The existing directory of <http://www.iana.org/numbers.html>. The existing directory of
registration forms and RFC 3066 registrations will be relabeled as registration forms and RFC 3066 registrations will be relabeled as
"Language Tags (Obsolete)" and maintained (but not added to or "Language Tags (Obsolete)" and maintained (but not added to or
modified). modified).
Future work on the Language Subtag Registry will be limited to Future work on the Language Subtag Registry will 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. Each record will be sent to iana@iana.org with a subject document. Each record will be sent to iana@iana.org with a subject
line indicating whether the enclosed record is an insertion (of a new line indicating whether the enclosed record is an insertion (of a new
record) or a replacment of an existing record which has a Type and record) or a replacement of an existing record which has a Type and
Subtag (or Tag) field that exactly matches the record sent. Records Subtag (or Tag) field that exactly matches the record sent. Records
cannot be deleted from the registry. cannot be deleted from the 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
skipping to change at page 46, line 21 skipping to change at page 46, line 21
This is a special case of the general problem that anything sent is This is a special case of the general problem that anything sent is
visible to the receiving party and possibly to third parties as well. visible to the receiving party and possibly to third parties as well.
It is useful to be aware that such concerns can exist in some cases. It is useful to be aware that such concerns can exist in some cases.
The evaluation of the exact magnitude of the threat, and any possible The evaluation of the exact magnitude of the threat, and any possible
countermeasures, is left to each application protocol (see BCP 72, countermeasures, is left to each application protocol (see BCP 72,
RFC 3552 [16] for best current practice guidance on security threats RFC 3552 [16] for best current practice guidance on security threats
and defenses). and defenses).
The language tag associated with a particular information item is of
no consequence whatsoever in determining whether that content might
contain possible homographs. The fact that a text is tagged as being
in one language or using a particular script subtag provides no
assurance whatsoever that it does not contain characters from scripts
other than the one(s) associated with or specified by that language
tag.
Since there is no limit to the number of variant, private use, and Since there is no limit to the number of variant, private use, and
extension subtags, and consequently no limit on the possible length extension subtags, and consequently no limit on the possible length
of a tag, implementations need to guard against buffer overflow of a tag, implementations need to guard against buffer overflow
attacks. See section Section 2.1.1 for details on language tag attacks. See Section 2.1.1 for details on language tag truncation,
truncation, which can occur as a consequence of defenses against which can occur as a consequence of defenses against buffer overflow.
buffer overflow.
Although the specification of valid subtags for an extension (see: Although the specification of valid subtags for an extension (see:
Section 3.6) MUST be available over the Internet, implementations Section 3.6) MUST be available over the Internet, implementations
SHOULD NOT mechanically depend on it being always accessible, to SHOULD NOT mechanically depend on it being always accessible, to
prevent denial-of-service attacks. prevent denial-of-service attacks.
7. Character Set Considerations 7. Character Set Considerations
The syntax in this document requires that language tags use only the The syntax in this document requires that language tags use only the
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
skipping to change at page 50, line 24 skipping to change at page 50, line 24
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-02 and this version are: Changes between draft-ietf-ltru-registry-04 and this version are:
o Modified the title and some of the front matter of Section 3.7
from "Conversion of the RFC 3066 Language Tag Registry"
(A.Phillips)
o Modified the rules for registry creation so that no variant
registrations are created ab initio. (#922) (J.Cowan)
o Modified the document to replace 'Canonical' with 'Preferred-
Value' and to implement the various design changes necessary to
deal with canonicalization. (#954) (F.Ellermann, A.Phillips, et
al)
o Corrected the ABNF so that 'lang' is defined as 2*4ALPHA (J.Cowan)
o Changed the requirement in Section 2.1.1 on truncation of tags
from MUST to SHOULD and added a sentence about the harm this may
cause. (F.Ellermann, D.Ewell)
o Changed "MUST be very compelling" to "must (etc.)" in Section 3.5.
(R.Presuhn)
o Changed "STRONGLY RECOMMENDED" to "strongly RECOMMENDED"
(R.Presuhn)
o Added sentences pertaining to the File-Date record to Section 3.1.
(#941) (R.Presuhn)
o Changed the process by which the prototype registry is created
from a mere document to an Informational RFC. (#838, #835) (??)
o Changed the Security Considerations (Section 6) and Length
Considerations (Section 2.1.1) sections to address potential
buffer overflow attacks and suggest a lower limit on buffer length
allocation (#944)(#965) (R.Presuhn, I.McDonald)
o Clarified a sentence in Security Considerations (Section 6) to
make clear that it refers to extensions and not the language
subtag registry. (#965) (I.McDonald)
o Added the limitation in the ABNF on the number of extlang subtags
(limited to three) (#965) (R.Presuhn, A.Phillips)
o Added notes to extlang and variant explaining that they should be o Changes to Section 2.1.1. Incorporated Frank Ellermann's text
used with their Recommended-Prefixes. (A.Phillips) about RFC 2231 and modified some conformance criteria. (#944)
o Changed the name of the 'Recommended-Prefix' field to 'Prefix' and o Changed Section 2.2.4 and added UN M.49 to the list of standards
the requirements for validating processors to require the prefix monitored for changes in Section 3.4, plus added some additional
with variants and extlangs. (#1018) (J.Cowan, F.Ellerman) squirms to Section 3.3 to ensure that ISO-3166-less UN M.49 codes
are not registered automagically but may be registered by
individuals given inaction on the part of ISO 3166 for 180 days.
Also made the assignments of UN M.49 codes in Section 2.2.4
normative (MUST instead of 'are'). Finally, the initial rules
were modified to reflect the foregoing in Section 3.7. (#1026)
(D.Ewell, P.Constable, A.Phillips)
o Added notes about when variants may be used together and the o Added text to Section 3.5 allowing new entries and other changes
relationship of the 'Prefix' field to this in Section 2.2.5 per the rules in Section 3.3 (A.Phillips)
(A.Phillips)
o Specified that 'Prefix' fields may be added only to 'variant' o Added text to Section 2.2.4 and Section 3.3 forbidding the
subtag records and not to 'extlang' records. (J.Cowan) registration of UN M.49 country or area codes not assigned an ISO
3166 code. (#1026) (A.Phillips)
o Converted lowercase RFC 2119 words to their RFC 2119 normative o Harmonized the rules pertaining to position and number of script
equivalent. A few exceptions remain (where the words functioned and region subtags (basically now they say that they MUST occur
in a non-normative fashion). (I.McDonald) only once and MAY be omitted) (A.Phillips)
o Rewrote Section 2.1.1 so that it deals with a canonical minimum o Added the homograph paragraph to Section 6. (#967)(R.Presuhn)
maximum length, etc. (#944)
9. References 9. References
9.1 Normative References 9.1 Normative References
[1] International Organization for Standardization, "ISO 639- [1] International Organization for Standardization, "ISO 639-
1:2002, Codes for the representation of names of languages -- 1:2002, Codes for the representation of names of languages --
Part 1: Alpha-2 code", ISO Standard 639, 2002. Part 1: Alpha-2 code", ISO Standard 639, 2002.
[2] International Organization for Standardization, "ISO 639-2:1998 [2] International Organization for Standardization, "ISO 639-2:1998
skipping to change at page 52, line 48 skipping to change at page 51, line 48
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", draft-crocker-abnf-rfc2234bis-00 (work Specifications: ABNF", draft-crocker-abnf-rfc2234bis-00 (work
in progress), March 2005. in progress), March 2005.
[8] Bradner, S., "The Internet Standards Process -- Revision 3", [8] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[9] Hovey, R. and S. Bradner, "The Organizations Involved in the [9] Hovey, R. and S. Bradner, "The Organizations Involved in the
IETF Standards Process", BCP 11, RFC 2028, October 1996. IETF Standards Process", BCP 11, RFC 2028, October 1996.
[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement [10] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
November 1996.
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[12] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", [13] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
RFC 2781, February 2000. RFC 2781, February 2000.
[13] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of [14] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the Internet Understanding Concerning the Technical Work of the Internet
Assigned Numbers Authority", RFC 2860, June 2000. Assigned Numbers Authority", RFC 2860, June 2000.
[14] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[15] Klyne, G. and C. Newman, "Date and Time on the Internet: [15] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002. Timestamps", RFC 3339, July 2002.
[16] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on [16] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", BCP 72, RFC 3552, July 2003. Security Considerations", BCP 72, RFC 3552, July 2003.
9.2 Informative References 9.2 Informative References
[17] ISO 639 Joint Advisory Committee, "ISO 639 Joint Advisory [17] ISO 639 Joint Advisory Committee, "ISO 639 Joint Advisory
Committee: Working principles for ISO 639 maintenance", Committee: Working principles for ISO 639 maintenance",
skipping to change at page 56, line 29 skipping to change at page 55, line 29
zh-Hant (Chinese written using the Traditional Chinese script) zh-Hant (Chinese written using the Traditional Chinese script)
zh-Hans (Chinese written using the Simplified Chinese script) zh-Hans (Chinese written using the Simplified Chinese script)
sr-Cyrl (Serbian written using the Cyrillic script) sr-Cyrl (Serbian written using the Cyrillic script)
sr-Latn (Serbian written using the Latin script) sr-Latn (Serbian written using the Latin script)
Language-Script-Region: Language-Script-Region:
zh-Hans-CN (Chinese written using the Simlified script as used in zh-Hans-CN (Chinese written using the Simplified script as used in
mainland China) mainland China)
sr-Latn-CS (Serbian written using the Latin script as used in sr-Latn-CS (Serbian written using the Latin script as used in
Serbia and Montenegro) Serbia and Montenegro)
Language-Variant: Language-Variant:
en-boont (Boontling dialect of English) en-boont (Boontling dialect of English)
en-scouse (Scouse dialect of English) en-scouse (Scouse dialect of English)
 End of changes. 

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