tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5646

 
 
 

Tags for Identifying Languages

Part 2 of 4, p. 21 to 46
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 21 
3.  Registry Format and Maintenance

   The IANA Language Subtag Registry ("the registry") contains a
   comprehensive list of all of the subtags valid in language tags.
   This allows implementers a straightforward and reliable way to
   validate language tags.  The registry will be maintained so that,
   except for extension subtags, it is possible to validate all of the
   subtags that appear in a language tag under the provisions of this
   document or its revisions or successors.  In addition, the meaning of
   the various subtags will be unambiguous and stable over time.  (The
   meaning of private use subtags, of course, is not defined by the
   registry.)

   This section defines the registry along with the maintenance and
   update procedures associated with it, as well as a registry for
   extensions to language tags (Section 3.7).

3.1.  Format of the IANA Language Subtag Registry

   The IANA Language Subtag Registry is a machine-readable file in the
   format described in this section, plus copies of the registration
   forms approved in accordance with the process described in
   Section 3.5.

   The existing registration forms for grandfathered and redundant tags
   taken from RFC 3066 have been maintained as part of the obsolete RFC
   3066 registry.  The subtags added to the registry by either [RFC4645]
   or [RFC5645] do not have separate registration forms (so no forms are
   archived for these additions).

3.1.1.  File Format

   The registry is a [Unicode] text file and consists of a series of
   records in a format based on "record-jar" (described in
   [record-jar]).  Each record, in turn, consists of a series of fields
   that describe the various subtags and tags.  The actual registry file
   is encoded using the UTF-8 [RFC3629] character encoding.

   Each field can be considered a single, logical line of characters.
   Each field contains a "field-name" and a "field-body".  These are
   separated by a "field-separator".  The field-separator is a COLON
   character (U+003A) plus any surrounding whitespace.  Each field is
   terminated by the newline sequence CRLF.  The text in each field MUST
   be in Unicode Normalization Form C (NFC).

Top      Up      ToC       Page 22 
   A collection of fields forms a "record".  Records are separated by
   lines containing only the sequence "%%" (U+0025 U+0025).

   Although fields are logically a single line of text, each line of
   text in the file format is limited to 72 bytes in length.  To
   accommodate this, the field-body can be split into a multiple-line
   representation; this is called "folding".  Folding is done according
   to customary conventions for line-wrapping.  This is typically on
   whitespace boundaries, but can occur between other characters when
   the value does not include spaces, such as when a language does not
   use whitespace between words.  In any event, there MUST NOT be breaks
   inside a multibyte UTF-8 sequence or in the middle of a combining
   character sequence.  For more information, see [UAX14].

   Although the file format uses the Unicode character set and the file
   itself is encoded using the UTF-8 encoding, fields are restricted to
   the printable characters from the US-ASCII [ISO646] repertoire unless
   otherwise indicated in the description of a specific field
   (Section 3.1.2).

   The format of the registry is described by the following ABNF
   [RFC5234].  Character numbers (code points) are taken from Unicode,
   and terminals in the ABNF productions are in terms of characters
   rather than bytes.

   registry   = record *("%%" CRLF record)
   record     = 1*field
   field      = ( field-name field-sep field-body CRLF )
   field-name = (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)]
   field-sep  = *SP ":" *SP
   field-body = *([[*SP CRLF] 1*SP] 1*CHARS)
   CHARS      = (%x21-10FFFF)      ; Unicode code points

                      Figure 3: Registry Format ABNF

   The sequence '..'  (U+002E U+002E) in a field-body denotes a range of
   values.  Such a range represents all subtags of the same length that
   are in alphabetic or numeric order within that range, including the
   values explicitly mentioned.  For example, 'a..c' denotes the values
   'a', 'b', and 'c', and '11..13' denotes the values '11', '12', and
   '13'.

   All fields whose field-body contains a date value use the "full-date"
   format specified in [RFC3339].  For example, "2004-06-28" represents
   June 28, 2004, in the Gregorian calendar.

Top      Up      ToC       Page 23 
3.1.2.  Record and Field Definitions

   There are three types of records in the registry: "File-Date",
   "Subtag", and "Tag".

   The first record in the registry is always the "File-Date" record.
   This record occurs only once in the file and contains a single field
   whose field-name is "File-Date".  The field-body of this record
   contains a date (see Section 5.1), making it possible to easily
   recognize different versions of the registry.

   File-Date: 2004-06-28
   %%

                 Figure 4: Example of the File-Date Record

   Subsequent records contain multiple fields and represent information
   about either subtags or tags.  Both types of records have an
   identical structure, except that "Subtag" records contain a field
   with a field-name of "Subtag", while, unsurprisingly, "Tag" records
   contain a field with a field-name of "Tag".  Field-names MUST NOT
   occur more than once per record, with the exception of the
   'Description', 'Comments', and 'Prefix' fields.

   Each record MUST contain at least one of each of the following
   fields:

   o  'Type'

      *  Type's field-body MUST consist of one of the following strings:
         "language", "extlang", "script", "region", "variant",
         "grandfathered", and "redundant"; it denotes the type of tag or
         subtag.

   o  Either 'Subtag' or 'Tag'

      *  Subtag's field-body contains the subtag being defined.  This
         field MUST appear in all records whose 'Type' has one of these
         values: "language", "extlang", "script", "region", or
         "variant".

      *  Tag's field-body contains a complete language tag.  This field
         MUST appear in all records whose 'Type' has one of these
         values: "grandfathered" or "redundant".  If the 'Type' is
         "grandfathered", then the 'Tag' field-body will be one of the
         tags listed in either the 'regular' or 'irregular' production
         found in Section 2.1.

Top      Up      ToC       Page 24 
   o  'Description'

      *  Description's field-body contains a non-normative description
         of the subtag or tag.

   o  'Added'

      *  Added's field-body contains the date the record was registered
         or, in the case of grandfathered or redundant tags, the date
         the corresponding tag was registered under the rules of
         [RFC1766] or [RFC3066].

   Each record MAY also contain the following fields:

   o  'Deprecated'

      *  Deprecated's field-body contains the date the record was
         deprecated.  In some cases, this value is earlier than that of
         the 'Added' field in the same record.  That is, the date of
         deprecation preceded the addition of the record to the
         registry.

   o  'Preferred-Value'

      *  Preferred-Value's field-body contains a canonical mapping from
         this record's value to a modern equivalent that is preferred in
         its place.  Depending on the value of the 'Type' field, this
         value can take different forms:

         +  For fields of type 'language', 'Preferred-Value' contains
            the primary language subtag that is preferred when forming
            the language tag.

         +  For fields of type 'script', 'region', or 'variant',
            'Preferred-Value' contains the subtag of the same type that
            is preferred for forming the language tag.

         +  For fields of type 'extlang', 'grandfathered', or
            'redundant', 'Preferred-Value' contains an "extended
            language range" [RFC4647] that is preferred for forming the
            language tag.  That is, the preferred language tag will
            contain, in order, each of the subtags that appears in the
            'Preferred-Value'; additional fields can be included in a
            language tag, as described elsewhere in this document.  For
            example, the replacement for the grandfathered tag "zh-min-
            nan" (Min Nan Chinese) is "nan", which can be used as the

Top      Up      ToC       Page 25 
            basis for tags such as "nan-Hant" or "nan-TW" (note that the
            extended language subtag form such as "zh-nan-Hant" or "zh-
            nan-TW" can also be used).

   o  'Prefix'

      *  Prefix's field-body contains a valid language tag that is
         RECOMMENDED as one possible prefix to this record's subtag.
         This field MAY appear in records whose 'Type' field-body is
         either 'extlang' or 'variant' (it MUST NOT appear in any other
         record type).

   o  'Suppress-Script'

      *  Suppress-Script's field-body contains a script subtag that
         SHOULD NOT be used to form language tags with the associated
         primary or extended language subtag.  This field MUST appear
         only in records whose 'Type' field-body is 'language' or
         'extlang'.  See Section 4.1.

   o  'Macrolanguage'

      *  Macrolanguage's field-body contains a primary language subtag
         defined by ISO 639 as the "macrolanguage" that encompasses this
         language subtag.  This field MUST appear only in records whose
         'Type' field-body is either 'language' or 'extlang'.

   o  'Scope'

      *  Scope's field-body contains information about a primary or
         extended language subtag indicating the type of language code
         according to ISO 639.  The values permitted in this field are
         "macrolanguage", "collection", "special", and "private-use".
         This field only appears in records whose 'Type' field-body is
         either 'language' or 'extlang'.  When this field is omitted,
         the language is an individual language.

   o  'Comments'

      *  Comments's field-body contains additional information about the
         subtag, as deemed appropriate for understanding the registry
         and implementing language tags using the subtag or tag.

   Future versions of this document might add additional fields to the
   registry; implementations SHOULD ignore fields found in the registry
   that are not defined in this document.

Top      Up      ToC       Page 26 
3.1.3.  Type Field

   The field 'Type' contains the string identifying the record type in
   which it appears.  Values for the 'Type' field-body are: "language"
   (Section 2.2.1); "extlang" (Section 2.2.2); "script" (Section 2.2.3);
   "region" (Section 2.2.4); "variant" (Section 2.2.5); "grandfathered"
   or "redundant" (Section 2.2.8).

3.1.4.  Subtag and Tag Fields

   The field 'Subtag' contains the subtag defined in the record.  The
   field 'Tag' appears in records whose 'Type' is either 'grandfathered'
   or 'redundant' and contains a tag registered under [RFC3066].

   The 'Subtag' field-body MUST follow the casing conventions described
   in Section 2.1.1.  All subtags use lowercase letters in the field-
   body, with two exceptions:

      Subtags whose 'Type' field is 'script' (in other words, subtags
      defined by ISO 15924) MUST use titlecase.

      Subtags whose 'Type' field is 'region' (in other words, the non-
      numeric region subtags defined by ISO 3166-1) MUST use all
      uppercase.

   The 'Tag' field-body MUST be formatted according to the rules
   described in Section 2.1.1.

3.1.5.  Description Field

   The field 'Description' contains a description of the tag or subtag
   in the record.  The 'Description' field MAY appear more than once per
   record.  The 'Description' field MAY include the full range of
   Unicode characters.  At least one of the 'Description' fields MUST be
   written or transcribed into the Latin script; additional
   'Description' fields MAY be in any script or language.

   The 'Description' field is used for identification purposes.
   Descriptions SHOULD contain all and only that information necessary
   to distinguish one subtag from others with which it might be
   confused.  They are not intended to provide general background
   information or to provide all possible alternate names or
   designations.  'Description' fields don't necessarily represent the
   actual native name of the item in the record, nor are any of the
   descriptions guaranteed to be in any particular language (such as
   English or French, for example).

Top      Up      ToC       Page 27 
   Descriptions in the registry that correspond to ISO 639, ISO 15924,
   ISO 3166-1, or UN M.49 codes are intended only to indicate the
   meaning of that identifier as defined in the source standard at the
   time it was added to the registry or as subsequently modified, within
   the bounds of the stability rules (Section 3.4), via subsequent
   registration.  The 'Description' does not replace the content of the
   source standard itself.  'Description' fields are not intended to be
   the localized English names for the subtags.  Localization or
   translation of language tag and subtag descriptions is out of scope
   of this document.

   For subtags taken from a source standard (such as ISO 639 or ISO
   15924), the 'Description' fields in the record are also initially
   taken from that source standard.  Multiple descriptions in the source
   standard are split into separate 'Description' fields.  The source
   standard's descriptions MAY be edited or modified, either prior to
   insertion or via the registration process, and additional or
   extraneous descriptions omitted or removed.  Each 'Description' field
   MUST be unique within the record in which it appears, and formatting
   variations of the same description SHOULD NOT occur in that specific
   record.  For example, while the ISO 639-1 code 'fy' has both the
   description "Western Frisian" and the description "Frisian, Western"
   in that standard, only one of these descriptions appears in the
   registry.

   To help ensure that users do not become confused about which subtag
   to use, 'Description' fields assigned to a record of any specific
   type ('language', 'extlang', 'script', and so on) MUST be unique
   within that given record type with the following exception: if a
   particular 'Description' field occurs in multiple records of a given
   type, then at most one of the records can omit the 'Deprecated'
   field.  All deprecated records that share a 'Description' MUST have
   the same 'Preferred-Value', and all non-deprecated records MUST be
   that 'Preferred-Value'.  This means that two records of the same type
   that share a 'Description' are also semantically equivalent and no
   more than one record with a given 'Description' is preferred for that
   meaning.

   For example, consider the 'language' subtags 'zza' (Zaza) and 'diq'
   (Dimli).  It so happens that 'zza' is a macrolanguage enclosing 'diq'
   and thus also has a description in ISO 639-3 of "Dimli".  This
   description was edited to read "Dimli (macrolanguage)" in the
   registry record for 'zza' to prevent a collision.

   By contrast, the subtags 'he' and 'iw' share a 'Description' value of
   "Hebrew"; this is permitted because 'iw' is deprecated and its
   'Preferred-Value' is 'he'.

Top      Up      ToC       Page 28 
   For fields of type 'language', the first 'Description' field
   appearing in the registry corresponds whenever possible to the
   Reference Name assigned by ISO 639-3.  This helps facilitate cross-
   referencing between ISO 639 and the registry.

   When creating or updating a record due to the action of one of the
   source standards, the Language Subtag Reviewer MAY edit descriptions
   to correct irregularities in formatting (such as misspellings,
   inappropriate apostrophes or other punctuation, or excessive or
   missing spaces) prior to submitting the proposed record to the
   ietf-languages@iana.org list for consideration.

3.1.6.  Deprecated Field

   The field 'Deprecated' contains the date the record was deprecated
   and MAY be added, changed, or removed from any record via the
   maintenance process described in Section 3.3 or via the registration
   process described in Section 3.5.  Usually, the addition of a
   'Deprecated' field is due to the action of one of the standards
   bodies, such as ISO 3166, withdrawing a code.  Although valid in
   language tags, subtags and tags with a 'Deprecated' field are
   deprecated, and validating processors SHOULD NOT generate these
   subtags.  Note that a record that contains a 'Deprecated' field and
   no corresponding 'Preferred-Value' field has no replacement mapping.

   In some historical cases, it might not have been possible to
   reconstruct the original deprecation date.  For these cases, an
   approximate date appears in the registry.  Some subtags and some
   grandfathered or redundant tags were deprecated before the initial
   creation of the registry.  The exact rules for this appear in Section
   2 of [RFC4645].  Note that these records have a 'Deprecated' field
   with an earlier date then the corresponding 'Added' field!

3.1.7.  Preferred-Value Field

   The field 'Preferred-Value' contains a mapping between the record in
   which it appears and another tag or subtag (depending on the record's
   'Type').  The value in this field is used for canonicalization (see
   Section 4.5).  In cases where the subtag or tag also has a
   'Deprecated' field, then the 'Preferred-Value' is RECOMMENDED as the
   best choice to represent the value of this record when selecting a
   language tag.

   Records containing a 'Preferred-Value' fall into one of these four
   groups:

Top      Up      ToC       Page 29 
   1.  ISO 639 language codes that were later withdrawn in favor of
       other codes.  These values are mostly a historical curiosity.
       The 'he'/'iw' pairing above is an example of this.

   2.  Subtags (with types other than language or extlang) taken from
       codes or values that have been withdrawn in favor of a new code.
       In particular, this applies to region subtags taken from ISO
       3166-1, because sometimes a country will change its name or
       administration in such a way that warrants a new region code.  In
       some cases, countries have reverted to an older name, which might
       already be encoded.  For example, the subtag 'ZR' (Zaire) was
       replaced by the subtag 'CD' (Democratic Republic of the Congo)
       when that country's name was changed.

   3.  Tags or subtags that have become obsolete because the values they
       represent were later encoded.  Many of the grandfathered or
       redundant tags were later encoded by ISO 639, for example, and
       fall into this grouping.  For example, "i-klingon" was deprecated
       when the subtag 'tlh' was added.  The record for "i-klingon" has
       a 'Preferred-Value' of 'tlh'.

   4.  Extended language subtags always have a mapping to their
       identical primary language subtag.  For example, the extended
       language subtag 'yue' (Cantonese) can be used to form the tag
       "zh-yue".  It has a 'Preferred-Value' mapping to the primary
       language subtag 'yue', meaning that a tag such as
       "zh-yue-Hant-HK" can be canonicalized to "yue-Hant-HK".

   Records other than those of type 'extlang' that contain a 'Preferred-
   Value' field MUST also have a 'Deprecated' field.  This field
   contains the date on which the tag or subtag was deprecated in favor
   of the preferred value.

   For records of type 'extlang', the 'Preferred-Value' field appears
   without a corresponding 'Deprecated' field.  An implementation MAY
   ignore these preferred value mappings, although if it ignores the
   mapping, it SHOULD do so consistently.  It SHOULD also treat the
   'Preferred-Value' as equivalent to the mapped item.  For example, the
   tags "zh-yue-Hant-HK" and "yue-Hant-HK" are semantically equivalent
   and ought to be treated as if they were the same tag.

   Occasionally, the deprecated code is preferred in certain contexts.
   For example, both "iw" and "he" can be used in the Java programming
   language, but "he" is converted on input to "iw", which is thus the
   canonical form in Java.

Top      Up      ToC       Page 30 
   'Preferred-Value' mappings in records of type 'region' sometimes do
   not represent exactly the same meaning as the original value.  There
   are many reasons for a country code to be changed, and the effect
   this has on the formation of language tags will depend on the nature
   of the change in question.  For example, the region subtag 'YD'
   (Democratic Yemen) was deprecated in favor of the subtag 'YE' (Yemen)
   when those two countries unified in 1990.

   A 'Preferred-Value' MAY be added to, changed, or removed from records
   according to the rules in Section 3.3.  Addition, modification, or
   removal of a 'Preferred-Value' field in a record does not imply that
   content using the affected subtag needs to be retagged.

   The 'Preferred-Value' fields in records of type "grandfathered" and
   "redundant" each contain an "extended language range" [RFC4647] that
   is strongly RECOMMENDED for use in place of the record's value.  In
   many cases, these mappings were created via deprecation of the tags
   during the period before [RFC4646] was adopted.  For example, the tag
   "no-nyn" was deprecated in favor of the ISO 639-1-defined language
   code 'nn'.

   The 'Preferred-Value' field in subtag records of type "extlang" also
   contains an "extended language range".  This allows the subtag to be
   deprecated in favor of either a single primary language subtag or a
   new language-extlang sequence.

   Usually, the addition, removal, or change of a 'Preferred-Value'
   field for a subtag is done to reflect changes in one of the source
   standards.  For example, if an ISO 3166-1 region code is deprecated
   in favor of another code, that SHOULD result in the addition of a
   'Preferred-Value' field.

   Changes to one subtag can affect other subtags as well: when
   proposing changes to the registry, the Language Subtag Reviewer MUST
   review the registry for such effects and propose the necessary
   changes using the process in Section 3.5, although anyone MAY request
   such changes.  For example:

      Suppose that subtag 'XX' has a 'Preferred-Value' of 'YY'.  If 'YY'
      later changes to have a 'Preferred-Value' of 'ZZ', then the
      'Preferred-Value' for 'XX' MUST also change to be 'ZZ'.

      Suppose that a registered language subtag 'dialect' represents a
      language not yet available in any part of ISO 639.  The later
      addition of a corresponding language code in ISO 639 SHOULD result
      in the addition of a 'Preferred-Value' for 'dialect'.

Top      Up      ToC       Page 31 
3.1.8.  Prefix Field

   The field 'Prefix' contains a valid language tag that is RECOMMENDED
   as one possible prefix to this record's subtag, perhaps with other
   subtags.  That is, when including an extended language or a variant
   subtag that has at least one 'Prefix' in a language tag, the
   resulting tag SHOULD match at least one of the subtag's 'Prefix'
   fields using the "Extended Filtering" algorithm (see [RFC4647]), and
   each of the subtags in that 'Prefix' SHOULD appear before the subtag
   itself.

   The 'Prefix' field MUST appear exactly once in a record of type
   'extlang'.  The 'Prefix' field MAY appear multiple times (or not at
   all) in records of type 'variant'.  Additional fields of this type
   MAY be added to a 'variant' record via the registration process,
   provided the 'variant' record already has at least one 'Prefix'
   field.

   Each 'Prefix' field indicates a particular sequence of subtags that
   form a meaningful tag with this subtag.  For example, the extended
   language subtag 'cmn' (Mandarin Chinese) only makes sense with its
   prefix 'zh' (Chinese).  Similarly, 'rozaj' (Resian, a dialect of
   Slovenian) would be appropriate when used with its prefix 'sl'
   (Slovenian), while tags such as "is-1994" are not appropriate (and
   probably not meaningful).  Although the 'Prefix' for 'rozaj' is "sl",
   other subtags might appear between them.  For example, the tag "sl-
   IT-rozaj" (Slovenian, Italy, Resian) matches the 'Prefix' "sl".

   The 'Prefix' also indicates when variant subtags make sense when used
   together (many that otherwise share a 'Prefix' are mutually
   exclusive) and what the relative ordering of variants is supposed to
   be.  For example, the variant '1994' (Standardized Resian
   orthography) has several 'Prefix' fields in the registry ("sl-rozaj",
   "sl-rozaj-biske", "sl-rozaj-njiva", "sl-rozaj-osojs", and "sl-rozaj-
   solba").  This indicates not only that '1994' is appropriate to use
   with each of these five Resian variant subtags ('rozaj', 'biske',
   'njiva', 'osojs', and 'solba'), but also that it SHOULD appear
   following any of these variants in a tag.  Thus, the language tag
   ought to take the form "sl-rozaj-biske-1994", rather than "sl-1994-
   rozaj-biske" or "sl-rozaj-1994-biske".

   If a record includes no 'Prefix' field, a 'Prefix' field MUST NOT be
   added to the record at a later date.  Otherwise, changes (additions,
   deletions, or modifications) to the set of 'Prefix' fields MAY be
   registered, as long as they strictly widen the range of language tags
   that are recommended.  For example, a 'Prefix' with the value "be-
   Latn" (Belarusian, Latin script) could be replaced by the value "be"
   (Belarusian) but not by the value "ru-Latn" (Russian, Latin script)

Top      Up      ToC       Page 32 
   or the value "be-Latn-BY" (Belarusian, Latin script, Belarus), since
   these latter either change or narrow the range of suggested tags.

   The field-body of the 'Prefix' field MUST NOT conflict with any
   'Prefix' already registered for a given record.  Such a conflict
   would occur when no valid tag could be constructed that would contain
   the prefix, such as when two subtags each have a 'Prefix' that
   contains the other subtag.  For example, suppose that the subtag
   'avariant' has the prefix "es-bvariant".  Then the subtag 'bvariant'
   cannot be assigned the prefix 'avariant', for that would require a
   tag of the form "es-avariant-bvariant-avariant", which would not be
   valid.

3.1.9.  Suppress-Script Field

   The field 'Suppress-Script' contains a script subtag (whose record
   appears in the registry).  The field 'Suppress-Script' MUST appear
   only in records whose 'Type' field-body is either 'language' or
   'extlang'.  This field MUST NOT appear more than one time in a
   record.

   This field indicates a script used to write the overwhelming majority
   of documents for the given language.  The subtag for such a script
   therefore adds no distinguishing information to a language tag and
   thus SHOULD NOT be used for most documents in that language.
   Omitting the script subtag indicated by this field helps ensure
   greater compatibility between the language tags generated according
   to the rules in this document and language tags and tag processors or
   consumers based on RFC 3066.  For example, virtually all Icelandic
   documents are written in the Latin script, making the subtag 'Latn'
   redundant in the tag "is-Latn".

   Many language subtag records do not have a 'Suppress-Script' field.
   The lack of a 'Suppress-Script' might indicate that the language is
   customarily written in more than one script or that the language is
   not customarily written at all.  It might also mean that sufficient
   information was not available when the record was created and thus
   remains a candidate for future registration.

3.1.10.  Macrolanguage Field

   The field 'Macrolanguage' contains a primary language subtag (whose
   record appears in the registry).  This field indicates a language
   that encompasses this subtag's language according to assignments made
   by ISO 639-3.

   ISO 639-3 labels some languages in the registry as "macrolanguages".
   ISO 639-3 defines the term "macrolanguage" to mean "clusters of

Top      Up      ToC       Page 33 
   closely-related language varieties that [...] can be considered
   distinct individual languages, yet in certain usage contexts a single
   language identity for all is needed".  These correspond to codes
   registered in ISO 639-2 as individual languages that were found to
   correspond to more than one language in ISO 639-3.

   A language contained within a macrolanguage is called an "encompassed
   language".  The record for each encompassed language contains a
   'Macrolanguage' field in the registry; the macrolanguages themselves
   are not specially marked.  Note that some encompassed languages have
   ISO 639-1 or ISO 639-2 codes.

   The 'Macrolanguage' field can only occur in records of type
   'language' or 'extlang'.  Only values assigned by ISO 639-3 will be
   considered for inclusion.  'Macrolanguage' fields MAY be added or
   removed via the normal registration process whenever ISO 639-3
   defines new values or withdraws old values.  Macrolanguages are
   informational, and MAY be removed or changed if ISO 639-3 changes the
   values.  For more information on the use of this field and choosing
   between macrolanguage and encompassed language subtags, see
   Section 4.1.1.

   For example, the language subtags 'nb' (Norwegian Bokmal) and 'nn'
   (Norwegian Nynorsk) each have a 'Macrolanguage' field with a value of
   'no' (Norwegian).  For more information, see Section 4.1.

3.1.11.  Scope Field

   The field 'Scope' contains classification information about a primary
   or extended language subtag derived from ISO 639.  Most languages
   have a scope of 'individual', which means that the language is not a
   macrolanguage, collection, special code, or private use.  That is, it
   is what one would normally consider to be 'a language'.  Any primary
   or extended language subtag that has no 'Scope' field is an
   individual language.

   'Scope' information can sometimes be helpful in selecting language
   tags, since it indicates the purpose or "scope" of the code
   assignment within ISO 639.  The available values are:

   o  'macrolanguage' - Indicates a macrolanguage as defined by ISO
      639-3 (see Section 3.1.10).  A macrolanguage is a cluster of
      closely related languages that are sometimes considered to be a
      single language.

   o  'collection' - Indicates a subtag that represents a collection of
      languages, typically related by some type of historical,
      geographical, or linguistic association.  Unlike a macrolanguage,

Top      Up      ToC       Page 34 
      a collection can contain languages that are only loosely related
      and a collection cannot be used interchangeably with languages
      that belong to it.

   o  'special' - Indicates a special language code.  These are subtags
      used for identifying linguistic attributes not particularly
      associated with a concrete language.  These include codes for when
      the language is undetermined or for non-linguistic content.

   o  'private-use' - Indicates a code reserved for private use in the
      underlying standard.  Subtags with this scope can be used to
      indicate a primary language for which no ISO 639 or registered
      assignment exists.

   The 'Scope' field MAY appear in records of type 'language' or
   'extlang'.  Note that many of the prefixes for extended language
   subtags will have a 'Scope' of 'macrolanguage' (although some will
   not) and that many languages that have a 'Scope' of 'macrolanguage'
   will have extended language subtags associated with them.

   The 'Scope' field MAY be added, modified, or removed via the
   registration process, provided the change mirrors changes made by ISO
   639 to the assignment's classification.  Such a change is expected to
   be rare.

   For example, the primary language subtag 'zh' (Chinese) has a 'Scope'
   of 'macrolanguage', while its enclosed language 'nan' (Min Nan
   Chinese) has a 'Scope' of 'individual'.  The special value 'und'
   (Undetermined) has a 'Scope' of 'special'.  The ISO 639-5 collection
   'gem' (Germanic languages) has a 'Scope' of 'collection'.

3.1.12.  Comments Field

   The field 'Comments' contains additional information about the record
   and MAY appear more than once per record.  The field-body MAY include
   the full range of Unicode characters and is not restricted to any
   particular script.  This field MAY be inserted or changed via the
   registration process, and no guarantee of stability is provided.

   The content of this field is not restricted, except by the need to
   register the information, the suitability of the request, and by
   reasonable practical size limitations.  The primary reason for the
   'Comments' field is subtag identification -- to help distinguish the
   subtag from others with which it might be confused as an aid to
   usage.  Large amounts of information about the use, history, or
   general background of a subtag are frowned upon, as these generally
   belong in a registration request rather than in the registry.

Top      Up      ToC       Page 35 
3.2.  Language Subtag Reviewer

   The Language Subtag Reviewer moderates the ietf-languages@iana.org
   mailing list, responds to requests for registration, and performs the
   other registry maintenance duties described in Section 3.3.  Only the
   Language Subtag Reviewer is permitted to request IANA to change,
   update, or add records to the Language Subtag Registry.  The Language
   Subtag Reviewer MAY delegate list moderation and other clerical
   duties as needed.

   The Language Subtag Reviewer is appointed by the IESG for an
   indefinite term, subject to removal or replacement at the IESG's
   discretion.  The IESG will solicit nominees for the position (upon
   adoption of this document or upon a vacancy) and then solicit
   feedback on the nominees' qualifications.  Qualified candidates
   should be familiar with BCP 47 and its requirements; be willing to
   fairly, responsively, and judiciously administer the registration
   process; and be suitably informed about the issues of language
   identification so that the reviewer can assess the claims and draw
   upon the contributions of language experts and subtag requesters.

   The subsequent performance or decisions of the Language Subtag
   Reviewer MAY be appealed to the IESG under the same rules as other
   IETF decisions (see [RFC2026]).  The IESG can reverse or overturn the
   decisions of the Language Subtag Reviewer, provide guidance, or take
   other appropriate actions.

3.3.  Maintenance of the Registry

   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
   Subtag Reviewer MUST evaluate each change and determine the
   appropriate course of action according to the rules in this document.
   Such updates follow the registration process described in
   Section 3.5.  Usually, the Language Subtag Reviewer will start the
   process for the new or updated record by filling in the registration
   form and submitting it.  If a change to one of these standards takes
   place and the Language Subtag Reviewer does not do this in a timely
   manner, then any interested party MAY submit the form.  Thereafter,
   the registration process continues normally.

   Note that some registrations affect other subtags--perhaps more than
   one--as when a region subtag is being deprecated in favor of a new
   value.  The Language Subtag Reviewer is responsible for ensuring that
   any such changes are properly registered, with each change requiring
   its own registration form.

Top      Up      ToC       Page 36 
   The Language Subtag Reviewer MUST ensure that new subtags meet the
   requirements elsewhere in this document (and most especially in
   Section 3.4) or submit an appropriate registration form for an
   alternate subtag as described in that section.  Each individual
   subtag affected by a change MUST be sent to the
   ietf-languages@iana.org list with its own registration form and in a
   separate message.

3.4.  Stability of IANA Registry Entries

   The stability of entries and their meaning in the registry is
   critical to the long-term stability of language tags.  The rules in
   this section guarantee that a specific language tag's meaning is
   stable over time and will not change.

   These rules specifically deal with how changes to codes (including
   withdrawal and deprecation of codes) maintained by ISO 639, ISO
   15924, ISO 3166, and UN M.49 are reflected in the IANA Language
   Subtag Registry.  Assignments to the IANA Language Subtag Registry
   MUST follow the following stability rules:

   1.   Values in the fields 'Type', 'Subtag', 'Tag', and 'Added' MUST
        NOT be changed and are guaranteed to be stable over time.

   2.   Values in the fields 'Preferred-Value' and 'Deprecated' MAY be
        added, altered, or removed via the registration process.  These
        changes SHOULD be limited to changes necessary to mirror changes
        in one of the underlying standards (ISO 639, ISO 15924, ISO
        3166-1, or UN M.49) and typically alteration or removal of a
        'Preferred-Value' is limited specifically to region codes.

   3.   Values in the 'Description' field MUST NOT be changed in a way
        that would invalidate any existing tags.  The description MAY be
        broadened somewhat in scope, changed to add information, or
        adapted to the most common modern usage.  For example, countries
        occasionally change their names; a historical example of this is
        "Upper Volta" changing to "Burkina Faso".

   4.   Values in the field 'Prefix' MAY be added to existing records of
        type 'variant' via the registration process, provided the
        'variant' already has at least one 'Prefix'.  A 'Prefix' field
        SHALL NOT be registered for any 'variant' that has no existing
        'Prefix' field.  If a prefix is added to a variant record,
        'Comment' fields MAY be used to explain different usages with
        the various prefixes.

Top      Up      ToC       Page 37 
   5.   Values in the field 'Prefix' in records of type 'variant' MAY
        also be modified, so long as the modifications broaden the set
        of prefixes.  That is, a prefix MAY be replaced by one of its
        own prefixes.  For example, the prefix "en-US" could be replaced
        by "en", but not by the prefixes "en-Latn", "fr", or "en-US-
        boont".  If one of those prefix values were needed, it would
        have to be separately registered.

   6.   Values in the field 'Prefix' in records of type 'extlang' MUST
        NOT be added, modified, or removed.

   7.   The field 'Prefix' MUST NOT be removed from any record in which
        it appears.  This field SHOULD be included in the initial
        registration of any records of type 'variant' and MUST be
        included in any records of type 'extlang'.

   8.   The field 'Comments' MAY be added, changed, modified, or removed
        via the registration process or any of the processes or
        considerations described in this section.

   9.   The field 'Suppress-Script' MAY be added or removed via the
        registration process.

   10.  The field 'Macrolanguage' MAY be added or removed via the
        registration process, but only in response to changes made by
        ISO 639.  The 'Macrolanguage' field appears whenever a language
        has a corresponding macrolanguage in ISO 639.  That is, the
        'Macrolanguage' fields in the registry exactly match those of
        ISO 639.  No other macrolanguage mappings will be considered for
        registration.

   11.  The field 'Scope' MAY be added or removed from a primary or
        extended language subtag after initial registration, and it MAY
        be modified in order to match any changes made by ISO 639.
        Changes to the 'Scope' field MUST mirror changes made by ISO
        639.  Note that primary or extended language subtags whose
        records do not contain a 'Scope' field (that is, most of them)
        are individual languages as described in Section 3.1.11.

   12.  Primary and extended language subtags (other than independently
        registered values created using the registration process) are
        created according to the assignments of the various parts of ISO
        639, as follows:

        A.  Codes assigned by ISO 639-1 that do not conflict with
            existing two-letter primary language subtags and that have
            no corresponding three-letter primary defined in the
            registry are entered into the IANA registry as new records

Top      Up      ToC       Page 38 
            of type 'language'.  Note that languages given an ISO 639-1
            code cannot be given extended language subtags, even if
            encompassed by a macrolanguage.

        B.  Codes assigned by ISO 639-3 or ISO 639-5 that do not
            conflict with existing three-letter primary language subtags
            and that do not have ISO 639-1 codes assigned (or expected
            to be assigned) are entered into the IANA registry as new
            records of type 'language'.  Note that these two standards
            now comprise a superset of ISO 639-2 codes.  Codes that have
            a defined 'macrolanguage' mapping at the time of their
            registration MUST contain a 'Macrolanguage' field.

        C.  Codes assigned by ISO 639-3 MAY also be considered for an
            extended language subtag registration.  Note that they MUST
            be assigned a primary language subtag record of type
            'language' even when an 'extlang' record is proposed.  When
            considering extended language subtag assignment, these
            criteria apply:

            1.  If a language has a macrolanguage mapping, and that
                macrolanguage has other encompassed languages that are
                assigned extended language subtags, then the new
                language SHOULD have an 'extlang' record assigned to it
                as well.  For example, any language with a macrolanguage
                of 'zh' or 'ar' would be assigned an 'extlang' record.

            2.  'Extlang' records SHOULD NOT be created for languages if
                other languages encompassed by the macrolanguage do not
                also include 'extlang' records.  For example, if a new
                Serbo-Croatian ('sh') language were registered, it would
                not get an extlang record because other languages
                encompassed, such as Serbian ('sr'), do not include one
                in the registry.

            3.  Sign languages SHOULD have an 'extlang' record with a
                'Prefix' of 'sgn'.

            4.  'Extlang' records MUST NOT be created for items already
                in the registry.  Extended language subtags will only be
                considered at the time of initial registration.

            5.  Extended language subtag records MUST include the fields
                'Prefix' and 'Preferred-Value' with field values
                assigned as described in Section 2.2.2.

        D.  Any other codes assigned by ISO 639-2 that do not conflict
            with existing three-letter primary or extended language

Top      Up      ToC       Page 39 
            subtags and that do not have ISO 639-1 two-letter codes
            assigned are entered into the IANA registry as new records
            of type 'language'.  This type of registration is not
            supposed to occur in the future.

   13.  Codes assigned by ISO 15924 and ISO 3166-1 that do not conflict
        with existing subtags of the associated type and whose meaning
        is not the same as an existing subtag of the same type are
        entered into the IANA registry as new records.

   14.  Codes assigned by ISO 639, ISO 15924, or ISO 3166-1 that are
        withdrawn by their respective maintenance or registration
        authority remain valid in language tags.  A 'Deprecated' field
        containing the date of withdrawal MUST be added to the record.
        If a new record of the same type is added that represents a
        replacement value, then a 'Preferred-Value' field MAY also be
        added.  The registration process MAY be used to add comments
        about the withdrawal of the code by the respective standard.

           For example: the region code 'TL' was assigned to the country
           'Timor-Leste', replacing the code 'TP' (which was assigned to
           'East Timor' when it was under administration by Portugal).
           The subtag 'TP' remains valid in language tags, but its
           record contains the 'Preferred-Value' of 'TL' and its field
           'Deprecated' contains the date the new code was assigned
           ('2004-07-06').

   15.  Codes assigned by ISO 639, ISO 15924, or ISO 3166-1 that
        conflict with existing subtags of the associated type, including
        subtags that are deprecated, MUST NOT be entered into the
        registry.  The following additional considerations apply to
        subtag values that are reassigned:

        A.  For ISO 639 codes, if the newly assigned code's meaning is
            not represented by a subtag in the IANA registry, the
            Language Subtag Reviewer, as described in Section 3.5, SHALL
            prepare a proposal for entering in the IANA registry, as
            soon as practical, a registered language subtag as an
            alternate value for the new code.  The form of the
            registered language subtag will be at the discretion of the
            Language Subtag Reviewer and MUST conform to other
            restrictions on language subtags in this document.

        B.  For all subtags whose meaning is derived from an external
            standard (that is, by ISO 639, ISO 15924, ISO 3166-1, or UN
            M.49), if a new meaning is assigned to an existing code and
            the new meaning broadens the meaning of that code, then the
            meaning for the associated subtag MAY be changed to match.

Top      Up      ToC       Page 40 
            The meaning of a subtag MUST NOT be narrowed, however, as
            this can result in an unknown proportion of the existing
            uses of a subtag becoming invalid.  Note: the ISO 639
            registration authority (RA) has adopted a similar stability
            policy.

        C.  For ISO 15924 codes, if the newly assigned code's meaning is
            not represented by a subtag in the IANA registry, the
            Language Subtag Reviewer, as described in Section 3.5, SHALL
            prepare a proposal for entering in the IANA registry, as
            soon as practical, a registered variant subtag as an
            alternate value for the new code.  The form of the
            registered variant subtag will be at the discretion of the
            Language Subtag Reviewer and MUST conform to other
            restrictions on variant subtags in this document.

        D.  For ISO 3166-1 codes, if the newly assigned code's meaning
            is associated with the same UN M.49 code as another 'region'
            subtag, then the existing region subtag remains as the
            preferred value for that region and no new entry is created.
            A comment MAY be added to the existing region subtag
            indicating the relationship to the new ISO 3166-1 code.

        E.  For ISO 3166-1 codes, if the newly assigned code's meaning
            is associated with a UN M.49 code that is not represented by
            an existing region subtag, then the Language Subtag
            Reviewer, as described in Section 3.5, SHALL prepare a
            proposal for entering the appropriate UN M.49 country code
            as an entry in the IANA registry.

        F.  For ISO 3166-1 codes, if there is no associated UN numeric
            code, then the Language Subtag Reviewer SHALL petition the
            UN to create one.  If there is no response from the UN
            within 90 days of the request being sent, the Language
            Subtag Reviewer SHALL prepare a proposal for entering in the
            IANA registry, as soon as practical, a registered variant
            subtag as an alternate value for the new code.  The form of
            the registered variant subtag will be at the discretion of
            the Language Subtag Reviewer and MUST conform to other
            restrictions on variant subtags in this document.  This
            situation is very unlikely to ever occur.

   16.  UN M.49 has codes for both "countries and areas" (such as '276'
        for Germany) and "geographical regions and sub-regions" (such as
        '150' for Europe).  UN M.49 country or area codes for which
        there is no corresponding ISO 3166-1 code MUST NOT be
        registered, except as a surrogate for an ISO 3166-1 code that is
        blocked from registration by an existing subtag.

Top      Up      ToC       Page 41 
        If such a code becomes necessary, then the maintenance agency
        for ISO 3166-1 SHALL first be petitioned to assign a code to the
        region.  If the petition for a code assignment by ISO 3166-1 is
        refused or not acted on in a timely manner, the registration
        process described in Section 3.5 can then be used to register
        the corresponding UN M.49 code.  This way, UN M.49 codes remain
        available as the value of last resort in cases where ISO 3166-1
        reassigns a deprecated value in the registry.

   17.  The redundant and grandfathered entries together form the
        complete list of tags registered under [RFC3066].  The redundant
        tags are those previously registered tags that can now be formed
        using the subtags defined in the registry.  The grandfathered
        entries include those that can never be legal because they are
        'irregular' (that is, they do not match the 'langtag' production
        in Figure 1), are limited by rule (subtags such as 'nyn' and
        'min' look like the extlang production, but cannot be registered
        as extended language subtags), or their subtags are
        inappropriate for registration.  All of the grandfathered tags
        are listed in either the 'regular' or the 'irregular'
        productions in the ABNF.  Under [RFC4646] it was possible for
        grandfathered tags to become redundant.  However, all of the
        tags for which this was possible became redundant before this
        document was produced.  So the set of redundant and
        grandfathered tags is now permanent and immutable: new entries
        of either type MUST NOT be added and existing entries MUST NOT
        be removed.  The decision-making process about which tags were
        initially grandfathered and which were made redundant is
        described in [RFC4645].

        Many of the grandfathered tags are deprecated -- indeed, they
        were deprecated even before [RFC4646].  For example, the tag
        "art-lojban" was deprecated in favor of the primary language
        subtag 'jbo'.  These tags could have been made 'redundant' by
        registering some of their subtags as 'variants'.  The 'variant-
        like' subtags in the grandfathered registrations SHALL NOT be
        registered in the future, even with a similar or identical
        meaning.

3.5.  Registration Procedure for Subtags

   The procedure given here MUST be used by anyone who wants to use a
   subtag not currently in the IANA Language Subtag Registry or who
   wishes to add, modify, update, or remove information in existing
   records as permitted by this document.

   Only subtags of type 'language' and 'variant' will be considered for
   independent registration of new subtags.  Subtags needed for

Top      Up      ToC       Page 42 
   stability and subtags necessary to keep the registry synchronized
   with ISO 639, ISO 15924, ISO 3166, and UN M.49 within the limits
   defined by this document also use this process, as described in
   Section 3.3 and subject to stability provisions as described in
   Section 3.4.

   Registration requests are accepted relating to information in the
   'Comments', 'Deprecated', 'Description', 'Prefix', 'Preferred-Value',
   'Macrolanguage', or 'Suppress-Script' fields in a subtag's record as
   described in Section 3.4.  Changes to all other fields in the IANA
   registry are NOT permitted.

   Registering a new subtag or requesting modifications to an existing
   tag or subtag starts with the requester filling out the registration
   form reproduced below.  Note that each response is not limited in
   size so that the request can adequately describe the registration.
   The fields in the "Record Requested" section need to follow the
   requirements in Section 3.1 before the record will be approved.

   LANGUAGE SUBTAG REGISTRATION FORM
   1. Name of requester:
   2. E-mail address of requester:
   3. Record Requested:

      Type:
      Subtag:
      Description:
      Prefix:
      Preferred-Value:
      Deprecated:
      Suppress-Script:
      Macrolanguage:
      Comments:

   4. Intended meaning of the subtag:
   5. Reference to published description
      of the language (book or article):
   6. Any other relevant information:

              Figure 5: The Language Subtag Registration Form

   Examples of completed registration forms can be found in Appendix B.
   A complete list of approved registration forms is online through
   http://www.iana.org; readers should note that the Language Tag
   Registry is now obsolete and should instead look for the Language
   Subtag Registry.

Top      Up      ToC       Page 43 
   The subtag registration form MUST be sent to
   <ietf-languages@iana.org>.  Registration requests receive a two-week
   review period before being approved and submitted to IANA for
   inclusion in the registry.  If modifications are made to the request
   during the course of the registration process (such as corrections to
   meet the requirements in Section 3.1 or to make the 'Description'
   fields unique for the given record type), the modified form MUST also
   be sent to <ietf-languages@iana.org> at least one week prior to
   submission to IANA.

   The ietf-languages list is an open list and can be joined by sending
   a request to <ietf-languages-request@iana.org>.  The list can be
   hosted by IANA or any third party at the request of IESG.

   Before forwarding any registration to IANA, the Language Subtag
   Reviewer MUST ensure that all requirements in this document are met.
   This includes ensuring that values in the 'Subtag' field match case
   according to the description in Section 3.1.4 and that 'Description'
   fields are unique for the given record type as described in
   Section 3.1.5.  The Reviewer MUST also ensure that an appropriate
   File-Date record is included in the request, to assist IANA when
   updating the registry (see Section 5.1).

   Some fields in both the registration form as well as the registry
   record itself permit the use of non-ASCII characters.  Registration
   requests SHOULD use the UTF-8 encoding for consistency and clarity.
   However, since some mail clients do not support this encoding, other
   encodings MAY be used for the registration request.  The Language
   Subtag Reviewer is responsible for ensuring that the proper Unicode
   characters appear in both the archived request form and the registry
   record.  In the case of a transcription or encoding error by IANA,
   the Language Subtag Reviewer will request that the registry be
   repaired, providing any necessary information to assist IANA.

   Extended language subtags (type 'extlang'), by definition, are always
   encompassed by another language.  All records of type 'extlang' MUST,
   therefore, contain a 'Prefix' field at the time of registration.
   This 'Prefix' field can never be altered or removed, and requests to
   do so MUST be rejected.

   Variant subtags are usually registered for use with a particular
   range of language tags, and variant subtags based on the terminology
   of the language to which they are apply are encouraged.  For example,
   the subtag 'rozaj' (Resian) is intended for use with language tags
   that start with the primary language subtag "sl" (Slovenian), since
   Resian is a dialect of Slovenian.  Thus, the subtag 'rozaj' would be
   appropriate in tags such as "sl-Latn-rozaj" or "sl-IT-rozaj".  This
   information is stored in the 'Prefix' field in the registry.  Variant

Top      Up      ToC       Page 44 
   registration requests SHOULD include at least one 'Prefix' field in
   the registration form.

   Requests to assign an additional record of a given type with an
   existing subtag value MUST be rejected.  For example, the variant
   subtag 'rozaj' already exists in the registry, so adding a second
   record of type 'variant' with the subtag 'rozaj' is prohibited.

   The 'Prefix' field for a given registered variant subtag exists in
   the IANA registry as a guide to usage.  Additional 'Prefix' fields
   MAY be added by filing an additional registration form.  In that
   form, the "Any other relevant information:" field MUST indicate that
   it is the addition of a prefix.

   Requests to add a 'Prefix' field to a variant subtag that imply a
   different semantic meaning SHOULD be rejected.  For example, a
   request to add the prefix "de" to the subtag '1994' so that the tag
   "de-1994" represented some German dialect or orthographic form would
   be rejected.  The '1994' subtag represents a particular Slovenian
   orthography, and the additional registration would change or blur the
   semantic meaning assigned to the subtag.  A separate subtag SHOULD be
   proposed instead.

   Requests to add a 'Prefix' to a variant subtag that has no current
   'Prefix' field MUST be rejected.  Variants are registered with no
   prefix because they are potentially useful with many or even all
   languages.  Adding one or more 'Prefix' fields would be potentially
   harmful to the use of the variant, since it dramatically reduces the
   scope of the subtag (which is not allowed under the stability rules
   (Section 3.4) as opposed to broadening the scope of the subtag, which
   is what the addition of a 'Prefix' normally does.  An example of such
   a "no-prefix" variant is the subtag 'fonipa', which represents the
   International Phonetic Alphabet, a scheme that can be used to
   transcribe many languages.

   The 'Description' fields provided in the request MUST contain at
   least one description written or transcribed into the Latin script;
   the request MAY also include additional 'Description' fields in any
   script or language.  The 'Description' field is used for
   identification purposes and doesn't necessarily represent the actual
   native name of the language or variation.  It also doesn't have to be
   in any particular language, but SHOULD be both suitable and
   sufficient to identify the item in the record.  The Language Subtag
   Reviewer will check and edit any proposed 'Description' fields so as
   to ensure uniqueness and prevent collisions with 'Description' fields
   in other records of the same type.  If this occurs in an independent
   registration request, the Language Subtag Reviewer MUST resubmit the
   record to <ietf-languages@iana.org>, treating it as a modification of

Top      Up      ToC       Page 45 
   a request due to discussion, as described in Section 3.5, unless the
   request's sole purpose is to introduce a duplicate 'Description'
   field, in which case the request SHALL be rejected.

   The 'Description' field is not guaranteed to be stable.  Corrections
   or clarifications of intent are examples of possible changes.
   Attempts to provide translations or transcriptions of entries in the
   registry (which, by definition, provide no new information) are
   unlikely to be approved.

   Soon after the two-week review period has passed, the Language Subtag
   Reviewer MUST take one of the following actions:

   o  Explicitly accept the request and forward the form containing the
      record to be inserted or modified to <iana@iana.org> according to
      the procedure described in Section 3.3.

   o  Explicitly reject the request because of significant objections
      raised on the list or due to problems with constraints in this
      document (which MUST be explicitly cited).

   o  Extend the review period by granting an additional two-week
      increment to permit further discussion.  After each two-week
      increment, the Language Subtag Reviewer MUST indicate on the list
      whether the registration has been accepted, rejected, or extended.

   Note that the Language Subtag Reviewer MAY raise objections on the
   list if he or she so desires.  The important thing is that the
   objection MUST be made publicly.

   Sometimes the request needs to be modified as a result of discussion
   during the review period or due to requirements in this document.
   The applicant, Language Subtag Reviewer, or others MAY submit a
   modified version of the completed registration form, which will be
   considered in lieu of the original request with the explicit approval
   of the applicant.  Such changes do not restart the two-week
   discussion period, although an application containing the final
   record submitted to IANA MUST appear on the list at least one week
   prior to the Language Subtag Reviewer forwarding the record to IANA.
   The applicant MAY modify a rejected application with more appropriate
   or additional information and submit it again; this starts a new two-
   week comment period.

   Registrations initiated due to the provisions of Section 3.3 or
   Section 3.4 SHALL NOT be rejected altogether (since they have to
   ultimately appear in the registry) and SHOULD be completed as quickly
   as possible.  The review process allows list members to comment on
   the specific information in the form and the record it contains and

Top      Up      ToC       Page 46 
   thus help ensure that it is correct and consistent.  The Language
   Subtag Reviewer MAY reject a specific version of the form, but MUST
   propose a suitable replacement, extending the review period as
   described above, until the form is in a format worthy of the
   reviewer's approval and meets with rough consensus of the list.

   Decisions made by the Language Subtag Reviewer MAY be appealed to the
   IESG [RFC2028] under the same rules as other IETF decisions
   [RFC2026].  This includes a decision to extend the review period or
   the failure to announce a decision in a clear and timely manner.

   The approved records appear in the Language Subtag Registry.  The
   approved registration forms are available online from
   http://www.iana.org.

   Updates or changes to existing records follow the same procedure as
   new registrations.  The Language Subtag Reviewer decides whether
   there is consensus to update the registration following the two-week
   review period; normally, objections by the original registrant will
   carry extra weight in forming such a consensus.

   Registrations are permanent and stable.  Once registered, subtags
   will not be removed from the registry and will remain a valid way in
   which to specify a specific language or variant.

   Note: The purpose of the "Reference to published description" section
   in the registration form is to aid in verifying whether a language is
   registered or to which language or language variation a particular
   subtag refers.  In most cases, reference to an authoritative grammar
   or dictionary of that language will be useful; in cases where no such
   work exists, other well-known works describing that language or in
   that language MAY be appropriate.  The Language Subtag Reviewer
   decides what constitutes "good enough" reference material.  This
   requirement is not intended to exclude particular languages or
   dialects due to the size of the speaker population or lack of a
   standardized orthography.  Minority languages will be considered
   equally on their own merits.



(page 46 continued on part 3)

Next RFC Part