Network Working Group                                   A. Phillips, Ed.
Internet-Draft                                            Quest Software
Expires: September 11, October 28, 2005                                  M. Davis, Ed.
                                                                     IBM
                                                          March 10,
                                                          April 26, 2005

                     Tags for Identifying Languages
                      draft-ietf-ltru-registry-00
                      draft-ietf-ltru-registry-01

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.

   By submitting this Internet-Draft, each author represents that any
   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 become becomes
   aware will be disclosed, in accordance with
   RFC 3668. Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts. Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 11, October 28, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes the structure, content, construction, and
   semantics of language tags for use in cases where it is desirable to
   indicate the language used in an information object.  It also
   describes how to register values for use in language tags and the
   creation of user defined extensions for private interchange.  This
   document obsoletes RFC 3066 (which replaced RFC 1766).

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The Language Tag . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1   Syntax . . . . . . . . . . . . . . . . . . . . . . . . . .  4
       2.1.1   Length Considerations  . . . . . . . . . . . . . . . .   5  6
     2.2   Language Subtag Sources and Interpretation . . . . . . . .   6  7
       2.2.1   Primary Language Subtag  . . . . . . . . . . . . . . .   7  8
       2.2.2   Extended Language Subtags  . . . . . . . . . . . . . .   9 10
       2.2.3   Script Subtag  . . . . . . . . . . . . . . . . . . . .   9 10
       2.2.4   Region Subtag  . . . . . . . . . . . . . . . . . . . .  10 11
       2.2.5   Variant Subtags  . . . . . . . . . . . . . . . . . . .  11 12
       2.2.6   Extension Subtags  . . . . . . . . . . . . . . . . . .  11 13
       2.2.7   Private Use Subtags  . . . . . . . . . . . . . . . . .  12 14
       2.2.8   Pre-Existing RFC 3066 Registrations  . . . . . . . . .  13 15
       2.2.9  Possibilities for Registration   Classes of Conformance . . . . . . . . . . . . .  13
       2.2.10   Classes of Conformance . . . 15
   3.  Registry Format and Maintenance  . . . . . . . . . . . .  14
     2.3  Choice . . . 17
     3.1   Format of the IANA Language Tag Subtag Registry  . . . . . . . 17
     3.2   Maintenance of the Registry  . . . . . . . . . . . .  15
     2.4  Meaning of the Language Tag . . . 21
     3.3   Stability of IANA Registry Entries . . . . . . . . . . . .  16
       2.4.1  Canonicalization of Language Tags 22
     3.4   Registration Procedure for Subtags . . . . . . . . . .  17
     2.5  Considerations . . 25
     3.5   Possibilities for Private Use Subtags Registration . . . . . . . . . .  18
   3.   IANA Considerations . . . . 29
     3.6   Extensions and Extensions Namespace  . . . . . . . . . . . 30
     3.7   Conversion of the RFC 3066 Language Tag Registry . . . . .  20
     3.1  Format 33
   4.  Formation and Processing of the IANA Language Subtag Registry Tags  . . . . . . .  20
     3.2  Stability . . . 36
     4.1   Choice of IANA Registry Entries Language Tag . . . . . . . . . . . .  24
     3.3  Registration Procedure for Subtags . . . . . . 36
     4.2   Meaning of the Language Tag  . . . . . .  27
     3.4  Extensions and Extensions Namespace . . . . . . . . . 38
     4.3   Canonicalization of Language Tags  . . .  30
   4.   Security Considerations . . . . . . . . . 39
     4.4   Considerations for Private Use Subtags . . . . . . . . . .  32 40
   5.   Character Set  IANA Considerations  . . . . . . . . . . . . . . . .  33 . . . . . 42
   6.   Changes from RFC 3066  Security Considerations  . . . . . . . . . . . . . . . . . . .  34 43
   7.   References  Character Set Considerations . . . . . . . . . . . . . . . . . 44
   8.  Changes from RFC 3066  . . . . . . . .  36
        Authors' Addresses . . . . . . . . . . . . 45
   9.  References . . . . . . . . .  38
   A.   Acknowledgements . . . . . . . . . . . . . . . . . 50
     9.1   Normative References . . . . .  39
   B.   Examples of Language Tags (Informative) . . . . . . . . . .  40
   C.   Conversion of the RFC 3066 Language Tag Registry . . . . 50
     9.2   Informative References . .  42
        Intellectual Property and Copyright Statements . . . . . . .  44 . . . . . . . . . 51
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 52
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
   B.  Examples of Language Tags (Informative)  . . . . . . . . . . . 54
   C.  Example Registry . . . . . . . . . . . . . . . . . . . . . . . 57
       Intellectual Property and Copyright Statements . . . . . . . . 61

1.  Introduction

   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
   language used when presenting or requesting information.

   Information about a user's language preferences commonly needs to be
   identified so that appropriate processing can be applied.  For
   example, the user's language preferences in a browser can be used to
   select web pages appropriately.  A choice of language preference can
   also be used to select among tools (such as dictionaries) to assist
   in the processing or understanding of content in different languages.

   In addition, knowledge about the particular language used by some
   piece of information content may be useful or even required by some
   types of information processing; for example spell-checking,
   computer-synthesized speech, Braille transcription, or high-quality
   print renderings.

   One means of indicating the language used is by labeling the
   information content with a language identifier.  These identifiers
   can also be used to specify user preferences when selecting
   information content, or for labeling additional attributes of content
   and associated resources.

   These identifiers can also be used to indicate additional attributes
   of content that are closely related to the language.  In particular,
   it is often necessary to indicate specific information about the
   dialect, writing system, or orthography used in a document or
   resource, as these attributes may be important for the user to obtain
   information in a form that they can understand, or important in
   selecting appropriate processing resources for the given content.

   This document specifies an identifier mechanism and a registration
   function for values to be used with that identifier mechanism.  It
   also defines a mechanism for private use values and future extension.

   This document replaces RFC 3066, which replaced RFC 1766.  For a list
   of changes in this document, see Section 6. 8.

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119] [11]. [10].

2.  The Language Tag

2.1  Syntax

   The language tag is composed of one or more parts: A primary language
   subtag and a (possibly empty) series of subsequent subtags.  Subtags
   are distinguished by their length, position in the subtag sequence,
   and content, so that each type of subtag can be recognized solely by
   these features.  This makes it possible to construct a parser that
   can extract and assign some semantic information to the subtags, even
   if specific subtag values are not recognized.  Thus a parser need not
   have an up-to-date copy of the registered subtag values to perform
   most searching and matching operations.

   The syntax of this tag in ABNF [RFC 2234] [13] [7] is:

   Language-Tag = (lang
                   *("-" extlang)
                   ["-" script]
                   ["-" region]
                   *("-" variant)
                   *("-" extension)
                   ["-" privateuse])
                   / privateuse         ; private-use tag
                   / grandfathered      ; grandfathered registrations

   lang            = 2*3ALPHA           ; shortest ISO 639 code
                   / registered-lang
   extlang         = 3ALPHA             ; reserved for future use
   script          = 4ALPHA             ; ISO 15924 code
   region          = 2ALPHA             ; ISO 3166 code
                   / 3DIGIT             ; UN country number
   variant         = ALPHA (4*7alphanum)  5*8alphanum       ; registered variants
                   / ( DIGIT (3*7alphanum) 3alphanum )
   extension       = singleton 1*("-" (2*8alphanum)) ; extension subtag(s)
   privateuse      = ("x"/"X") 1*("-" (1*8alphanum)) ; private use subtag(s)
   singleton       = ("a"-"w" %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT
                   ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z") "Y"-"Z" / "0"-"9"
                   ; Single letters: x/X is reserved for private use
   registered-lang = 4*8ALPHA          ; registered language subtag
   grandfathered   = 1*3ALPHA 1*2("-" (2*8alphanum))
                                       ; grandfathered registration
                                       ; Note: i is the only singleton
                                       ; that starts
                                       ; a grandfathered tag
   alphanum        = (ALPHA / DIGIT)   ; letters and numbers

                        Figure 1: Language Tag ABNF

   The character "-" is HYPHEN-MINUS (ABNF: %x2D).  All subtags have a
   maximum length of eight characters.  Note that there is a subtlety in
   the ABNF for 'variant': variants starting with a digit may consist of sequences
   of up to eight characters. be only
   four characters long, while those starting with a letter must be at
   least five characters long.

   Whitespace is not permitted in a language tag.  For examples of
   language tags, see Appendix B.

   Note that although [RFC 2234] [13] [7] refers to octets, the language tags described
   in this document are sequences of characters from the US-ASCII
   repertoire.  Language tags may be used in documents and applications
   that use other encodings, so long as these encompass the US-ASCII
   repertoire.  An example of this would be an XML document that uses
   the Unicode UTF-16LE encoding. [12] encoding of Unicode [20].

   The tags and their subtags, including private-use and extensions, are
   to be treated as case insensitive: there exist conventions for the
   capitalization of some of the subtags, but these should not be taken
   to carry meaning.

   For example:

   o  [ISO 639] [1] recommends that language codes be written in lower
      case ('mn' Mongolian).

   o  [ISO 3166] [4] recommends that country codes be capitalized ('MN'
      Mongolia).

   o  [ISO 15924] [3] recommends that script codes use lower case with
      the initial letter capitalized ('Cyrl' Cyrillic).

   However, in the tags defined by this document, the uppercase US-ASCII
   letters in the range 'A' (ABNF: %x41) through 'Z' (ABNF: %x5A) are considered equivalent and
   mapped directly to their US-ASCII lowercase equivalents in the range
   'a' (ABNF: %x61) through 'z' (ABNF: %x7A). 'z'.  Thus the tag "mn-Cyrl-MN" is not distinct from "MN-cYRL-mn" "MN-
   cYRL-mn" or "mN-cYrL-Mn" (or any other combination) and each of these
   variations conveys the same meaning: Mongolian written in the
   Cyrillic script as used in Mongolia.

   For informative examples of language tags, see Appendix B at the end
   of this document.

2.1.1  Length Considerations

   Although neither the ABNF nor other guidelines in this document
   provide a fixed upper limit on the number of size of subtags in a Language
   Tag (and thus the upper bound on the size of a tag) and it is
   possible to envision quite long and complex subtag sequences, in
   practice these are rare because additional granularity in tags seldom
   adds useful distinguishing information and because longer, more
   granular tags interefere with the meaning, understanding, and
   processing of language tags.

   In particular,  variant subtags SHOULD be used only with their
   recommended prefix.  This  In practice, this limits most tags to a sequence
   of four
   subtags subtags, and thus a maximum length of 26 characters
   (excluding any extensions or private use sequences).  This is because
   subtags are limited to a length of eight characters and the extlang,
   script, and region subtags are limited to even fewer characters.  See
   Section 2.3 4.1 for more information on selecting the most appropriate
   Language Tag.

   A conformant implementation need not MAY refuse to support the storage of
   language tags which exceed a specified length.  For an example, see
   [RFC 2231]
   [12]. [22].  Any such a limitation MUST be clearly documented, and
   such documentation SHOULD include the disposition of any longer tags
   (for example, whether an error value is generated or the language tag
   is truncated).  If truncation is permitted it SHOULD NOT permit a
   subtag to be divided.

2.2  Language Subtag Sources and Interpretation

   The namespace of language tags and their subtags is administered by
   the Internet Assigned Numbers Authority (IANA) [17] [13] according to the
   rules in Section 3 5 of this document.  The registry maintained by IANA
   is the source for valid subtags: other standards referenced in this
   section provide the source material for that registry.

   Terminology in this section:

   o  Tag or tags refers to a complete language tag, such as
      "fr-Latn-CA".  Examples of tags in this document are enclosed in
      double-quotes ("en-US").

   o  Subtag refers to a specific section of a tag, separated delimited by hyphen,
      such as the subtag 'Latn' in "fr-Latn-CA".  Examples of subtags in
      this document are enclosed in single quotes ('Latn').

   o  Code or codes refers to tags values defined in external standards (and
      which are used as subtags in this document).  For example, 'Latn'
      is an [ISO 15924] [3] script code which was used to define the
      'Latn' script subtag for use in a language tag.  Examples of codes
      in this document are enclosed in single quotes ('en', 'Latn').

   The definitions in this section apply to the various subtags within
   the language tags defined by this document, excepting those
   "grandfathered" tags defined in Section 2.2.8.

   Language tags are designed so that each subtag type has unique length
   and content restrictions.  These make identification of the subtag's
   type possible, even if the content of the subtag itself is
   unrecognized.  This allows tags to be parsed and processed without
   reference to the latest version of the underlying standards or the
   IANA registry and makes the associated exception handling when
   parsing tags simpler.

   Subtags in the IANA registry that do not come from an underlying
   standard can only appear in specific positions in a tag.
   Specifically, they can only occur as primary language subtags or as
   variant subtags.

   Note that sequences of private-use and extension subtags MUST occur
   at the end of the sequence of subtags and MUST NOT be interspersed
   with subtags defined elsewhere in this document.

   Single letter and digit subtags are reserved for current or future
   use.  These include the following current uses:

   o  The single letter subtag 'x' is reserved to introduce a sequence
      of private-use subtags.  The interpretation of any private-use
      subtags is defined solely by private agreement and is not defined
      by the rules in this section or in any standard or registry
      defined in this document.

   o  All other single letter subtags are reserved to introduce
      standardized extension subtag sequences as described in
      Section 3.4. 3.6.

   The single letter subtag 'i' is used by some grandfathered tags, such
   as "i-enochian", where it always appears in the first position and
   cannot be confused with an extension.

2.2.1  Primary Language Subtag

   The primary language subtag is the first subtag in a language tag
   (with the exception of private-use and certain grandfathered tags)
   and cannot be empty.  Except as noted, the primary subtag is the language
   subtag. omitted.  The following rules apply to the assignment and
   interpretation of the primary
   language subtag:

   o

   1.  All 2-character two character language subtags were defined in the IANA
       registry according to the assignments found in the standard ISO
       639 Part 1, "ISO 639-1:2002, Codes for the representation of
       names of languages -- Part 1: Alpha-2 code" [ISO 639-1] [1], or
       using assignments subsequently made by the ISO 639 Part 1
       maintenance agency or governing standardization bodies.
   o

   2.  All 3-character three character language subtags were defined in the IANA
       registry according to the assignments found in ISO 639 Part 2,
       "ISO 639-2:1998 - Codes for the representation of names of
       languages -- Part 2: Alpha-3 code - edition 1" [ISO 639-2] [2],
       or assignments subsequently made by the ISO 639 Part 2
       maintenance agency or governing standardization bodies.
   o

   3.  The subtags in the range 'qaa' through 'qtz' are reserved for
       private use in language tags.  These subtags correspond to codes
       reserved by ISO 639-2 for private use.  These codes MAY be used
       for non-registered primary-language subtags (instead of using
       private-use subtags following 'x-').  Please refer to Section 2.5 4.4
       for more information on private use subtags.

   o

   4.  All four character language subtags are reserved for possible
       future standardization.

   5.  All language subtags of 4 5 to 8 characters in length in the IANA
       registry were defined via the registration process in Section 3.3 3.4
       and MAY be used to form the primary language subtag.  At the time
       this document was created, there were no examples of this kind of
       subtag and future registrations of this type will be discouraged:
       primary languages are STRONGLY RECOMMENDED for registration with
       ISO 639 and subtags proposals rejected by ISO 639 639/RA will be closely
       scrutinized before they are registered with IANA.
   o

   6.  The single character subtag 'x' as the primary subtag indicates
       that the language tag consists solely of subtags whose meaning is
       defined by private agreement.  For example, in the tag "x-fr-CH",
       the subtags 'fr' and 'CH' should not be taken to represent the
       French language or the country of Switzerland (or any other value
       in the IANA registry) unless there is a private agreement in
       place to do so.  See Section 2.5.
   o 4.4.

   7.  The single character subtag 'i' is used by some grandfathered
       tags (see Section 2.2.8) such as "i-klingon" and "i-bnn".  (Other
       grandfathered tags have a primary language subtag in their first
       position)

   8.  Other values MUST NOT be assigned to the primary subtag except by
       revision or update of this document.

   Note: For languages that have both an ISO 639-1 2-character two character code
   and an ISO 639-2 3-character three character code, only the ISO 639-1 2-character two
   character code is defined in the IANA registry.

   Note: For languages that have no ISO 639-1 2-character two character code and for
   which the ISO 639-2/T (Terminology) code and the ISO 639-2/B
   (Bibliographic) codes differ, only the Terminology code is defined in
   the IANA registry.  At the time this document was created, all
   languages that had both kinds of 3-character three character code were also
   assigned a 2-character two character code; it is not expected that future
   assignments of this nature will occur.

   Note: To avoid problems with versioning and subtag choice as
   experienced during the transition between RFC 1766 and RFC 3066, as
   well as the canonical nature of subtags defined by this document, the
   ISO 639 Registration Authority Joint Advisory Committee (ISO
   639/RA-JAC) 639/
   RA-JAC) has included the following statement in [6]: [16]:

   "A language code already in ISO 639-2 at the point of freezing ISO
   639-1 shall not later be added to ISO 639-1.  This is to ensure
   consistency in usage over time, since users are directed in Internet
   applications to employ the alpha-3 code when an alpha-2 code for that
   language is not available."

   In order to avoid instability of the canonical form of tags, if a
   2-character two
   character code is added to ISO 639-1 for a language for which a
   3-character three
   character code was already included in ISO 639-2, the 2-character two character
   code will not be added as a subtag in the registry.  See Section 3.2. 3.3.

   For example, if some content were tagged with 'haw' (Hawaiian), which
   currently has no 2-character two character code, the tag would not be invalidated
   if ISO 639-1 were to assign a 2-character two character code to the Hawaiian
   language at a later date.

   For example, one of the grandfathered IANA registrations is
   "i-enochian".  The subtag 'enochian' could be registered in the IANA
   registry as a primary language subtag (assuming that ISO 639 does not
   register this language first), making tags such as "enochian-AQ" and
   "enochian-Latn" valid.

2.2.2  Extended Language Subtags

   The following rules apply to the extended language subtags:

   o

   1.  Three letter subtags immediately following the primary subtag are
       reserved for future standardization, anticipating work that is
       currently under way on ISO 639.
   o

   2.  Extended language subtags MUST follow the primary subtag and
       precede any other subtags.
   o

   3.  There MAY be any additional number of extended language subtags.
   o

   4.  Extended language subtags will not be registered except by
       revision of this document.
   o

   5.  Extended language subtags MUST NOT be used to form language tags
       except by revision of this document.

   Example: In a future revision or update of this document, the tag
   "zh-gan" (registered under RFC 3066) might become a valid
   non-grandfathered non-
   grandfathered (that is, redundant) tag in which the subtag 'gan'
   might represent the Chinese dialect 'Gan'.

2.2.3  Script Subtag

   The following rules apply to the script subtags:

   o

   1.  All 4-character four character subtags were defined according to ISO 15924
       [3]--"Codes for the representation of the names of scripts":
       alpha-4 script codes, or subsequently assigned by the ISO 15924
       maintenance agency or governing standardization bodies, denoting
       the script or writing system used in conjunction with this
       language.
   o

   2.  Script subtags MUST immediately follow the primary language
       subtag and all extended language subtags and MUST occur before
       any other type of subtag described below.
   o

   3.  The script subtags 'Qaaa' through 'Qabx' are reserved for private
       use in language tags.  These subtags correspond to codes reserved
       by ISO 15924 for private use.  These codes MAY be used for non-registered non-
       registered script values.  Please refer to Section 2.5 4.4 for more
       information on private-use subtags.

   o

   4.  Script subtags cannot be registered using the process in
       Section 3.3 3.4 of this document.  Variant subtags may be considered
       for registration for that purpose.

   Example: "de-Latn" represents German written using the Latin script.

2.2.4  Region Subtag

   The following rules apply to the region subtags:

   o

   1.  The region subtag defines language variations used in a specific
       region, geographic, or political area.  Region subtags MUST
       follow any language, extended language, or script subtags and
       MUST precede all other subtags.
   o

   2.  All 2-character two character subtags following the primary subtag were
       defined in the IANA registry according to the assignments found
       in ISO 3166 [4]--"Codes for the representation of names of
       countries and their subdivisions - Part 1: Country
       codes"--alpha-2 country codes or assignments subsequently made by
       the ISO 3166 maintenance agency or governing standardization
       bodies.
   o

   3.  All 3-character three character codes consisting of digit (numeric)
       characters were defined in the IANA registry according to the
       assignments found in UN Standard Country or Area Codes for
       Statistical  Use [5] or assignments subsequently made by the
       governing standards body.  Note that not all of the UN M.49 codes
       are defined in the IANA registry:
      *

       A.  UN numeric codes assigned to 'macro-geographical
           (continental)' or sub-regions not associated with an assigned
           ISO 3166 alpha-2 code _are_ defined.
      *

       B.  UN numeric codes for 'economic groupings' or 'other
           groupings' are _not_ defined in the IANA registry and MUST
           NOT be used to form language tags.
      *  Countries

       C.  UN numeric codes for countries with ambiguous ISO 3166
           alpha-2 codes as defined in Section 3.2 3.3 are defined in the
           registry and are canonical for the given country or region
           defined.
      *

       D.  The alphanumeric codes in Appendix X of the UN document are
           _not_ defined 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.)
   o

   4.  There may be at most one region subtag in a language tag.
   o

   5.  The region subtags 'AA', 'QM'-'QZ', 'XA'-'XZ', and 'ZZ' are
       reserved for private use in language tags.  These subtags
       correspond to codes reserved by ISO 3166 for private use.  These
       codes MAY be used for private use region subtags (instead of
       using a private-use subtag sequence).  Please refer to
       Section 2.5 4.4 for more information on private use subtags.

   "de-Latn-CH"

   "de-CH" represents German ('de') written using the Latin script
   ('Latn') as used in Switzerland ('CH').

   "sr-Latn-CS" represents Serbian ('sr') written using Latin script
   ('Latn') as used in Serbia and Montenegro ('CS').

   "es-419" represents Spanish ('es') as used in the UN-defined Latin
   America and Caribbean region ('419').

2.2.5  Variant Subtags

   The following rules apply to the variant subtags:

   o

   1.  Variant subtags, as a collection in the IANA registry, subtags are not associated with any external standard.
       Variant subtags and their meanings are defined by the
       registration process defined in Section 3.3.
   o 3.4.

   2.  Variant subtags MUST follow all of the other defined subtags, but
       precede any extension or private-use subtag sequences.
   o

   3.  More than one variant MAY be used to form the language tag.
   o

   4.  Variant subtags MUST be registered with IANA according to the
       rules in Section 3.3 3.4 of this document before being used to form
       language tags.  In order to distinguish variants from other types
       of subtags, registrations must meet the following length and
       content restrictions:
      *

       1.  Variant subtags that begin with a letter (a-z, A-Z) MUST be
           at least five characters long.
      *

       2.  Variant subtags that begin with a digit (0-9) MUST be at
           least four characters long.
      *  The maximum length of a variant subtag is eight characters
         long.

   "en-boont"

   "en-scouse" represents the Boontling Scouse dialect of English.

   "de-CH-1996" represents German as used in Switzerland and as written
   using the spelling reform beginning in the year 1996 C.E.

2.2.6  Extension Subtags

   The following rules apply to extensions:

   o

   1.   Extension subtags are separated from the other subtags defined
        in this document by a single-letter subtag ("singleton").  The
        singleton MUST be one allocated to a registration authority via
        the mechanism described in Section 3.4 3.6 and cannot be the letter
        'x', which is reserved for private-use subtag sequences.
   o

   2.   Note: Private-use subtag sequences starting with the singleton
        subtag 'x' are described below.

   o

   3.   An extension MUST follow at least a primary language subtag.
        That is, a language tag cannot begin with an extension.
        Extensions extend language tags, they do not override or replace
        them.  For example, "a-value" is not a well-formed language tag,
        while "de-a-value" is.
   o

   4.   Each singleton subtag MUST appear at most one time in each tag
        (other than as a private-use subtag).  That is, singleton
        subtags MUST NOT be repeated.  For example, the tag "en-a-bbb-a-ccc" "en-a-bbb-a-
        ccc" is invalid because the subtag 'a' appears twice.
   o  Note that
        the tag "en-a-bbb-x-a-ccc" is valid because the second
        appearance of the singleton 'a' is in a private use sequence.

   5.   Extension subtags MUST meet all of the requirements for the
        content and format of subtags defined in this document.
   o

   6.   Extension subtags MUST meet whatever requirements are set by the
        document that defines their singleton prefix and whatever
        requirements are provided by the maintaining authority.
   o

   7.   Each extension subtag MUST be from two to eight characters long
        and consist solely of letters or digits, with each subtag
        separated by a single '-'.
   o

   8.   Each singleton MUST be followed by at least one extension
        subtag.  For example, the tag "tlh-a-b-foo" is invalid because
        the first singleton 'a' is followed immediately by another
        singleton 'b'.
   o

   9.   Extension subtags MUST follow all language, extended language,
        script, region and variant subtags in a tag.
   o

   10.  All subtags following the singleton and before another singleton
        are part of the extension.  Example: In the tag "fr-a-Latn", the
        subtag 'Latn' does not represent the script subtag 'Latn'
        defined in the IANA Language Subtag Registry.  Its meaning is
        defined by the extension 'a'.
   o

   11.  In the event that more than one extension appears in a single
        tag, the tag SHOULD be canonicalized as described in
        Section 2.4.1. 4.3.

   For example, if the prefix singleton 'r' and the shown subtags were
   defined, then the following tag would be a valid example:
   "en-Latn-GB-boont-r-extended-sequence-x-private" "en-Latn-
   GB-boont-r-extended-sequence-x-private"

2.2.7  Private Use Subtags

   The following rules apply to private-use subtags:

   o

   1.  Private-use subtags are separated from the other subtags defined
       in this document by the reserved single-character subtag 'x'.
   o

   2.  Private-use subtags MUST follow all language, extended language,
       script, region, variant, and extension subtags in the tag.
       Another way of saying this is that all subtags following the
       singleton 'x' MUST be considered private use.  Example: The
       subtag 'US' in the tag "en-x-US" is a private use subtag.
   o  Unlike Extensions, a

   3.  A tag MAY consist entirely of private-use subtags.

   o

   4.  No source is defined for private use subtags.  Use of private use
       subtags is by private agreement and SHOULD NOT be considered part
      of this document. only.

   For example: Users who wished to utilize SIL Ethnologue for
   identification might agree to exchange tags such as
   "az-Arab-x-AZE-derbend". "az-Arab-x-AZE-
   derbend".  This example contains two private-use subtags.  The first
   is 'AZE' and the second is 'derbend'.

2.2.8  Pre-Existing RFC 3066 Registrations

   Existing IANA-registered language tags from RFC 1766 and/or RFC 3066
   that are not defined by additions to this document
   maintain their validity.  IANA will maintain these tags in the
   registry under either the "grandfathered" or "redundant" type.  For
   more information see
   Appendix C. Section 3.7.

   It is important to note that all language tags formed under the
   guidelines in this document were either legal, well-formed tags or
   were valid for potential registration
   could have been registered under RFC 3066.

2.2.9  Possibilities for Registration

   Possibilities for registration  Classes of subtags include:

   o  Primary language subtags for languages not listed in ISO 639 that
      are not variants Conformance

   Implementations may wish to express their level of any listed or registered language, can be
      registered.  At conformance with
   the time rules and practices described in this document was created there were no
      examples document.  There are
   generally two classes of this form conforming implementations: "well-formed"
   processors and "validating" processors.  Claims of subtag.  Before attempting conformance SHOULD
   explicitly reference one of these definitions.

   An implementation that claims to register a check for well-formed language subtag, there MUST be an attempt tags
   MUST:

   o  Check that the tag and all of its subtags, including extension and
      private-use subtags, conform to register the language
      with ISO 639.  No language ABNF or that the tag is on the
      list of grandfathered tags.

   o  Check that singleton subtags will be registered for codes that exist in ISO 639-1 or ISO 639-2, which are under
      consideration by identify extensions do not
      repeat.  For example, the ISO 639 maintenance or registration
      authorities, or which have never been attempted for registration
      with those authorities.  If ISO 639 has previously rejected a
      language for registration, it tag "en-a-xx-b-yy-a-zz" is reasonable not well-
      formed.

   Well-formed processors are strongly encouraged to assume implement the
   canonicalization rules contained in Section 4.3.

   An implementation that there
      MUST claims to be additional very compelling evidence of need before it will
      be registered in validating MUST:

   o  Check that the IANA tag is well-formed.

   o  Specify the particular registry (to date for which the extent that it is very
      unlikely that any subtags will be registered implementation
      performs validation of this type). subtags.

   o  Dialect or other divisions or variations within  Check that either the tag is a language, its
      orthography, writing system, regional variation, grandfathered tag, or historical
      usage may be registered as that all
      language, script, region, and variant subtags.  An example is subtags consist of valid
      codes for use in language tags according to the
      'scouse' subtag (the Scouse dialect IANA registry as
      of English).

   This document leaves the decision on what subtags are appropriate or
   not to particular date specified by the registration process described implementation.

   o  Specify which, if any, extension RFCs as defined in Section 3.3.

   ISO 639 defines a maintenance agency for additions to 3.6
      are supported, including version, revision, and changes date.

   o  For any such extensions supported, check that all subtags used in
      that extension are valid.

   o  If the list of languages processor generates tags, it MUST do so in ISO 639. canonical form,
      including any supported extensions, as defined in Section 4.3.

3.  Registry Format and Maintenance

   This agency is:

   International Information Centre for Terminology (Infoterm)
   Aichholzgasse 6/12, AT-1120
   Wien, Austria
   Phone: +43 1 26 75 35 Ext.  312 Fax: +43 1 216 32 72

   ISO 639-2 section defines a maintenance agency for additions to the Language Subtag Registry and changes
   in the list of languages in ISO 639-2.  This agency is:

   Library of Congress
   Network Development maintenance
   and MARC Standards Office
   Washington, D.C.  20540 USA
   Phone: +1 202 707 6237  Fax: +1 202 707 0115
   URL: http://www.loc.gov/standards/iso639

   The maintenance agency for ISO 3166 (country codes) is:

   ISO 3166 Maintenance Agency
   c/o International Organization for Standardization
   Case postale 56
   CH-1211 Geneva 20 Switzerland
   Phone: +41 22 749 72 33  Fax: +41 22 749 73 49
   URL: http://www.iso.org/iso/en/prods-services/iso3166ma/index.html

   The registration authority for ISO 15924 (script codes) is:

   Unicode Consortium Box 391476
   Mountain View, CA 94039-1476, USA
   URL: http://www.unicode.org/iso15924 update procedures associated with it.

   The Statistics Division of the United Nations Secretariat maintains
   the Standard Country or Area Codes for Statistical Use and can language subtag registry will be
   reached at:

   Statistical Services Branch
   Statistics Division
   United Nations, Room DC2-1620
   New York, NY 10017, USA

   Fax: +1-212-963-0623
   E-mail: statistics@un.org
   URL: http://unstats.un.org/unsd/methods/m49/m49alpha.htm

2.2.10  Classes of Conformance

   Implementations may wish maintained so that, except for
   extension subtags, it is possible to express their level validate all of conformance with the rules and practices described in this document.  There are
   generally two classes of conforming implementations: "well-formed"
   processors and "validating" processors.  Claims of conformance SHOULD
   explicitly reference one of these definitions.

   An implementation subtags that claims to check for well-formed
   appear in a language tags
   MUST:
   o  Check that the tag and all under the provisions of this document or its subtags, including extension
   revisions or successors.  In addition, the meaning of the various
   subtags will be unambiguous and stable over time.  (The meaning of
   private-use subtags, conform to the ABNF or that the tag of course, is on not defined by the IANA registry.)

   The registry defined under this document contains a comprehensive
   list of grandfathered tags.
   o  Check that singleton all of the subtags that identify extensions do not
      repeat.  For example, the tag "en-a-xx-b-yy-a-zz" is not
      well-formed.

   Well-formed processors are strongly encouraged to implement the
   canonicalization rules contained valid in Section 2.4.1.

   An implementation that claims language tags.  This allows
   implementers a straightforward and reliable way to be validating MUST:
   o  Check that the tag is well-formed.
   o  Specify the particular registry date for which the implementation
      performs validation validate language
   tags.

3.1  Format of subtags.
   o  Check that either the tag is a grandfathered tag, or that all
      language, script, region, and variant subtags IANA Language Subtag Registry

   The IANA Language Subtag Registry ("the registry") will consist of valid
      codes for use a
   text file that is machine readable in language tags according to the IANA registry as format described in this
   section, plus copies of the particular date specified registration forms approved by the implementation.
   o  Specify which, if any, extension RFCs as defined in Section 3.4
      are supported, including version, revision, and date.
   o  For any such extensions supported, check that all subtags used
   Language Subtag Reviewer in
      that extension are valid.
   o  If accordance with the processor generates tags, it MUST do so in canonical form,
      including any supported extensions, as defined process described in
   Section 2.4.1.

2.3  Choice 3.4.  With the exception of Language Tag

   One may occasionally the registration forms for
   grandfathered and redundant tags, no registration records will be faced with several possible tags
   maintained for the same
   body initial set of text.

   Interoperability is best served when all users use the same language
   tag subtags.

   The registry will be in order a modified record-jar format text file [17].
   Lines are limited to represent 72 characters, including all whitespace.

   Records are separated by lines containing only the same language.  If an application has
   requirements that make the rules here inapplicable, then that
   application risks damaging interoperability.  It is STRONGLY
   RECOMMENDED that users not define their own rules for language tag
   choice.

   Standards, protocols sequence "%%"
   (%x25.25).

   Each field can be viewed as a single, logical  line  of ASCII
   characters,  comprising  a field-name and applications that reference this document
   normatively but apply different rules to a field-body separated by a
   COLON character (%x3A).  For convenience, the ones given in field-body  portion  of
   this
   section MUST specify how  conceptual entity  can be split into a multiple-line
   representation; this is called "folding".  The format of the procedure varies from registry
   is described by the one given
   here.

   1.  Use as precise a tag as possible, but no more specific than following ABNF (per [7]):

   registry   = record *("%%" CRLF record)
   record     = 1*( field-name *SP ":" *SP field-body CRLF )
   field-name = *(ALPHA/NUM/"-")
   field-body = *(ASCCHAR/LWSP)
   ASCCHAR    = %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is
       justified.  For example, 'de' might suffice for tagging an email
       written %x26
   UNICHAR    = "&#x" 2*6HEXDIG ";"

   The sequence '..' (%x2E.2E) in German, while "de-CH-1996" is probably unnecessarily
       precise for such a task.
   2.  Avoid using field-body denotes a range of
   values.  Such a range represents all subtags of the same length that
   are not important for distinguishing
       content in an application.  For example, alphabetically within that range, including the script
       subtag in "en-Latn-US" is generally unnecessary, since nearly all
       English texts are written in values explicitly
   mentioned.  For example 'a..c' denotes the Latin script values 'a', 'b', and it is generally
       not important to filter out those few that are not.
   3.  Use the canonical subtag 'c'.

   Characters from outside the IANA registry US-ASCII repertoire, as well as the
   AMPERSAND character ("&", %x26) when it occurs in preference to
       any of its aliases.  For example, you should use 'he' for Hebrew a field-body are
   represented by a "Numeric Character Reference" using hexadecimal
   notation in preference to 'iw'.
   4.  You SHOULD NOT use the 'UND' (Undetermined) language subtag to
       label content, even if style used by XML 1.0 [18] (see
   <http://www.w3.org/TR/REC-xml/#dt-charref>).  This consists of the language is unknown.  Omitting
   sequence "&#x" (%x26.23.78) followed by a hexadecimal representation
   of the tag
       is preferred.  Some protocols character's code point in ISO/IEC 10646 [6] followed by a
   closing semicolon (%x3B).  For example, the EURO SIGN, U+20AC, would
   be represented by the sequence "&#x20AC;".  Note that the hexadecimal
   notation may force you to give have between two and six digits.

   All fields whose field-body contains a date value for use the language tag and "full-date"
   format specified in RFC 3339 [14].  For example: "2004-06-28"
   represents June 28, 2004 in the 'UND' subtag may be useful when matching
       language tags Gregorian calendar.

   The first record in certain situations.
   5.  You SHOULD NOT use the 'MUL' (Multiple) subtag if file contains the protocol
       allows you to use multiple languages, as single field whose field-
   name is "File-Date" and whose field-body contains the case for last
   modification date of the
       Content-Language header registry:

   File-Date: 2004-06-28
   %%

   Subsequent records represent subtags in HTTP.
   6.  You SHOULD NOT use the same variant subtag registry.  Each of the
   fields in each record MUST occur no more than once within
       a language tag.  For example, you should not use
       "en-US-boont-boont".

   To ensure consistent backward compatibility, this document contains
   several provisions to account for potential instability in once, unless otherwise
   noted below.  Each record MUST contain the
   standards used to define following fields:

   o  'Type'

      *  Type's field-value MUST consist of one of the subtags that make up language tags.
   These provisions mean that no language tag created under following
         strings: "language", "extlang", "script", "region", "variant",
         "grandfathered", and "redundant" and denotes the rules in
   this document will become obsolete.  In addition, tags that are in
   canonical form will always be in canonical form.

2.4  Meaning type of the Language Tag

   The language tag always defines a language as spoken (or written,
   signed or otherwise signaled) by human beings for communication
         subtag.

   o  Either 'Subtag' or 'Tag'

      *  Subtag's field-value contains the subtag being defined.  This
         field MUST only appear in records of
   information to other human beings.  Computer languages such as
   programming languages are explicitly excluded.

   If whose Type has one of
         these values: "language", "extlang", "script", "region", or
         "variant".

      *  Tag's field-value contains a complete language tag B tag.  This field
         MUST only appear in records whose Type has one of these values:
         "grandfathered" or "redundant".

   o  Description

      *  Description's field-value contains language tag A as a prefix, then B is
   typically "narrower" non-normative description
         of the subtag or "more specific" than A.  For example,
   "zh-Hant-TW" is tag.

   o  Added

      *  Added's field-value contains the date the record was added to
         the registry.

   The field 'Description' MAY appear more specific than "zh-Hant".

   This relationship is not guaranteed in all cases: specifically,
   languages that begin with the same sequence one time.  The
   'Description' field must contain a description of subtags are NOT
   guaranteed to be mutually intelligible, although they may be.  For
   example, the tag "az" shares a prefix with both "az-Latn"
   (Azerbaijani being
   registered written using or transcribed into the Latin script) and "az-Cyrl"
   (Azerbaijani written using the Cyrillic script).  A person fluent in
   one script script; it may also
   include a description in a non-Latin script.  The 'Description' field
   is used for identification purposes and should not be able taken to read
   represent the other, even though actual native name of the text
   might language or variation or to
   be identical.  Content tagged in any particular language.  Most descriptions are taken directly
   from source standards such as "az" most probably is written ISO 639 or ISO 3166.

   Note: Descriptions in just one script and thus might not be intelligible registry entries that correspond to a reader
   familiar with ISO 639,
   ISO 15924,  ISO 3166 or UN M.49 codes are intended only to indicate
   the other script.

   The relationship between meaning of that identifier as defined in the tag and source standard at
   the information time it relates was added to is
   defined by the standard describing registry.  The description does not
   replace the context in which it appears.
   Accordingly, this section can only give possible examples content of its
   usage.
   o  For a single information object, the associated language tags
      might source standard itself.  The descriptions
   are not intended to be interpreted as the set English localized names for the subtags.
   Localization or translation of languages that language tag and subtag descriptions
   is required for
      a complete comprehension out of scope of this document.

   Each record MAY also contain the complete object.  Example: Plain
      text documents. following fields:

   o  Canonical

      *  For an aggregation fields of information objects, the associated language
      tags could be taken as the set type 'language', 'extlang', 'script', 'region',
         and 'variant', a canonical mapping of languages used inside components this record to a subtag
         record of that aggregation.  Examples: Document stores and libraries.
   o the same 'Type'.

      *  For information objects whose purpose is fields of type 'grandfathered' and 'redundant', a canonical
         mapping to provide alternatives, a complete language tag.

   o  Deprecated

      *  Deprecated's field-value contains the associated date the record was
         deprecated.

   o  Recommended-Prefix

      *  Recommended-Prefix's field-value contains a language tags could tag with
         which this subtag may be regarded as used to form a hint that new language tag,
         perhaps with other subtags as well.  This field MUST only
         appear in records whose 'Type' field-value is 'variant' or
         'extlang'.  For example, the
      content 'Recommended-Prefix' for the
         variant 'scouse' is provided in several languages, and 'en', meaning that one has to
      inspect each of the alternatives in order to find its language or
      languages.  In this case, the presence of multiple tags "en-scouse" and
         "en-GB-scouse" might not
      mean that one needs to be multi-lingual to get complete
      understanding of appropriate while the document.  Example: MIME
      multipart/alternative. tag "is-scouse"
         is not.

   o  In markup languages, such as HTML and XML, language  Comments

      *  Comments contains additional information
      can be added to each part of the document identified by about the markup
      structure (including subtag, as
         deemed appropriate for understanding the whole document itself).  For example, one
      could write <span lang="FR">C'est la vie.</span> inside a
      Norwegian document; registry and
         implementing language tags using the Norwegian-speaking user could then access subtag or tag.

   o  Suppress-Script

      *  Suppress-Script contains a French-Norwegian dictionary to find out what the marked section
      meant.  If the user were listening to script subtag that document through a
      speech synthesis interface, this formation could SHOULD NOT be
         used to signal
      the synthesizer to appropriately apply French text-to-speech
      pronunciation rules to that span of text, instead of misapplying form language tags with the Norwegian rules.

2.4.1  Canonicalization of Language Tags

   Since a particular associated primary language tag may be used
         subtag.  This field MUST only appear in many processes,
   language tags SHOULD always records whose 'Type'
         field-value is 'language'.  See Section 4.1.

   The field 'Canonical' SHALL NOT be created or generated added to any record already in the
   registry.  The field 'Canonical' SHALL NOT be modified except for
   records of type "grandfathered": therefore a subtag whose record
   contains no canonical
   form.

   A language tag mapping when the record is in created is a
   canonical form when:
   1. and will remain so.

   The tag is well-formed according the rules 'Canonical' field in Section 2.1 and
       Section 2.2.
   2.  None records of the subtags in the type "grandfathered" and
   "redundant" contains whole language tag has a canonical_value
       mapping in the IANA registry (see Section 3.1).  Subtags with a
       canonical_value mapping MUST be replaced with their mapping tags that are STRONGLY
   RECOMMENDED for use in
       order to canonicalize place of the tag.
   3.  If more than one extension subtag sequence exists, record's value.  In many cases
   the extension
       sequences are ordered into case-insensitive ASCII order mappings were created by
       singleton subtag.

   Example: The language deprecation of the tags during the
   period before this document was adopted.  For example, the tag "en-A-aaa-B-ccc-bbb-x-xyz" is in canonical
   form, while "en-B-ccc-bbb-A-aaa-X-xyz" is well-formed but not "no-
   nyn" was deprecated in
   canonical form.

   Example: The favor of the ISO 639-1 defined language tag "en-NH" (English as used in code
   'nn'.

   Note that a record that has a 'Canonical' field MUST have a
   'Deprecated' field also (although the New
   Hebrides) converse is not canonical because the 'NH' subtag has a canonical
   mapping true).

   The field 'Deprecated' MAY be added to 'VU' (Vanuatu).

   Note: Canonicalization of language tags does not imply anything about any record via the use of upper or lowercase letter in subtags as maintenance
   process described in Section 2.1.  All comparisons MUST be performed in a case-insensitive
   manner.

   Note: 3.2 or via the value "--" registration process
   described in Section 3.4.  Usually the canonical_value addition of a 'Deprecated'
   field is due to the action of one of the registry
   indicates standards bodies, such as
   ISO 3166, withdrawing a tag or subtag that has code.  In some historical cases it may not
   have been deprecated  possible to reconstruct the original deprecation date.
   For these cases, an approximate date appears in the registry.
   Although valid in language tags, subtags and for which no
   replacement or canonical equivalent has been assigned.  Validating
   processors SHOULD NOT generate tags that include with a 'Deprecated'
   field are deprecated and validating processors SHOULD NOT generate
   these values.

   An extension MUST define any relationships subtags.  Note that may exist between the
   various subtags in the extension a record that contains a 'Deprecated' field
   and thus no corresponding 'Canonical' field has no replacement mapping.

   The field 'Recommended-Prefix' MAY define an alternate
   canonicalization scheme for the extension's subtags.  Extensions appear more than once per record.
   Additional fields of this type MAY
   define how be added to a record via the order
   registration process.  The field-value of the extension's subtags are interpreted.  For
   example, an extension could define that its subtags are in canonical
   order when the subtags are placed into ASCII order: that is,
   "en-a-aaa-bbb-ccc" instead of "en-a-ccc-bbb-aaa".  Another extension
   might define that the order this field consists of the subtags influences their semantic
   meaning (so that "en-b-ccc-bbb-aaa" has a different value from
   "en-b-aaa-bbb-ccc").  However, extension specifications SHOULD be
   designed so that they are tolerant of the typical processes described
   in Section 3.4.

2.5  Considerations for Private Use Subtags

   Private-use subtags require private agreement between the parties
   that intend to use or exchange
   language tags tag that use them and great
   caution should be used in employing them in content or protocols
   intended is RECOMMENDED for general use.  Private-use subtags are simply useless use as a prefix for
   information exchange without prior arrangement.

   The value and semantic meaning this subtag.
   For example, the variant subtag 'scouse' has a recommended prefix of private-use
   "en".  This means that tags and of starting with the subtags
   used within such a language tag prefix "en-" are not defined by most
   appropriate with this document.

   The use of subtags defined in subtag, so "en-Latn-scouse" and "en-GB-scouse"
   are both acceptable, while the IANA registry as having a specific
   private use meaning convey more information that a purely private use tag prefixed by the singleton subtag 'x'.  For applications "fr-scouse" is probably an
   inappropriate choice.

   The field of type Recommended-Prefix MUST NOT be removed from any
   record.  The field-value for this
   additional information may type of field MUST NOT be useful.

   For example, modified.

   The field 'Comments' MAY appear more than once per record.  This
   field MAY be inserted or changed via the region subtags 'AA', 'ZZ' registration process and in no
   guarantee of stability is provided.  The content of this field is not
   restricted, except by the ranges
   'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166 private use codes) may
   be used need to form a language tag.  A tag such as "zh-Hans-XQ" conveys a
   great deal register the information, the
   suitability of public, interchangeable information about the language
   material (that it request, and by reasonable practical size
   limitations.  Long screeds about a particular subtag are frowned
   upon.

   The field 'Suppress-Script' MUST only appear in records whose 'Type'
   field-value is Chinese 'language'.  This field may appear at most one time in the simplified Chinese
   a record.  This field indicates a script and is
   suitable for some geographic region 'XQ').  While used to write the precise
   geographic region is not known outside
   overwhelming majority of private agreement, documents for the tag
   conveys far more information than an opaque tag such as "x-someLang", given language and which contains
   therefore adds no distinguishing information about the to a language subtag or script
   subtag outside of the private agreement.

   However, tag.  For
   example, virtually all Icelandic documents are written in some cases content tagged with private use subtags may
   interact with other systems the Latin
   script, making the subtag 'Latn' redundant in a different the tag "is-Latn".

   For examples of registry entries and possibly unsuitable
   manner compared to tags that use opaque, privately defined subtags,
   so their format, see Appendix C.

3.2  Maintenance of the choice Registry

   Maintenance of the best approach may depend on registry requires that as new codes are assigned
   by ISO 639, ISO 15924, and ISO 3166, the particular
   domain in question.

3.  IANA Considerations

   This section deals Language Subtag Reviewer
   will evaluate each assignment, determine whether it conflicts with the processes
   existing registry entries, and requirements necessary submit the information to
   maintain IANA for
   inclusion in the registry of subtags registry.  If an assignment takes place and extensions for the
   Language Subtag Reviewer does not do this in a timely manner, then
   any interested party may use the procedure in language
   tags as defined by this document Section 3.4 to register
   the appropriate update.

   Note: The redundant and in accordance with grandfathered entries together are the
   requirements
   complete list of tags registered under RFC 2434 [15]. 3066 [23].  The language subtag registry will redundant
   tags are those that can now be maintained so that, except for
   extension subtags, it is possible to validate all of formed using the subtags that
   appear defined in a language tag under
   the provisions of this document or its
   revisions or successors.  In addition, registry together with the meaning rules of the various
   subtags will  Section 2.2.  The
   grandfathered entries are those that can never be unambiguous legal under those
   same provisions.  The items in both lists are permanent and stable stable,
   although grandfathered items may be deprecated over time.  (The meaning  Refer to
   Section 3.7 for more information.

   RFC 3066 tags that were deprecated prior to the adoption of
   private-use subtags, this
   document are part of course, is not defined by the IANA registry.)

   The registry defined under this document contains a comprehensive list of all of the grandfathered tags and their
   component subtags valid were not included as registered variants (although
   they remain eligible for registration).  For example, the tag "art-
   lojban" was deprecated in language tags.  This allows
   implementers a straightforward and reliable way to validate language
   tags.

3.1  Format favor of the IANA Language Subtag Registry language subtag 'jbo'.

   The IANA Language Subtag Registry will consist of a text file Reviewer MUST ensure that is
   machine readable in new subtags meet the format
   requirements in Section 4.1 or submit an appropriate alternate subtag
   as described in this section, plus copies
   of that section.  If a change or addition to the registration forms approved by
   registry is required, the Language Subtag Reviewer in
   accordance with the process described in Section 3.3.  With the
   exception of will prepare the registration forms for grandfathered
   complete record, including all fields, and redundant
   tags, no registration records will be maintained forward it to IANA for
   insertion into the initial set
   of subtags.

   Each record in registry.  If this represents a new subtag, then
   the subtag registry message will consist indicate that this represents an INSERTION of a series of fields
   separated by the symbol "|" (%x7D) and terminated by
   record.  If this represents a newline.  Text
   appearing after change to an existing subtag, then the symbol "#" (%x23) contains comments.  Whitespace
   surrounding fields
   message must indicate that this represents a MODIFICATION, as shown
   in the file following example:

   LANGUAGE SUBTAG MODIFICATION
   File-Date: 2005-01-02
   %%
   Type: variant
   Subtag: nedis
   Description: Natisone dialect
   Description: Nadiza dialect
   Added: 2003-10-09
   Recommended-Prefix: sl
   Comments: This is ignored.  If a field contains more
   than one value, the values are separated by semicolons (%x3B).

   There comment shown
     as an example.
   %%

                                 Figure 4

   Whenever an entry is a single date created or modified in the registry, the 'File-
   Date' record at the start of the file which
   indicates registry is updated to reflect the
   most recent modification date of in the file.  It has two
   fields: the type field is "date", and the second field is the
   modification date, in the "full-date" format specified in RFC 3339
   [20].  For example: 2004-06-28 represents June 28, 2004 in the
   Gregorian calendar:
      date | 2004-06-28

   The fields in each subtag record, in order, are:
      type| subtag| description| date| canonical_value|
      recommended_prefix # comments
   o [14] "full-date"
   format.

3.3  Stability of IANA Registry Entries

   The character "vertical line" ("|", %x7D) delimits each stability of the
      fields.
   o  Empty fields (and entries and their separators) at the end of the record may
      be omitted.
   o  Leading or trailing whitespace meaning in each field is not part of the
      content.
   o  When the type is "grandfathered" or "redundant", then the subtag
      field is actually a whole tag.
   o  The "recommended_prefix" field registry is empty, except where
   critical to the type is
      "variant"
   o long term stability of language tags.  The "comments" field rules in
   this section guarantee that a specific language tag's meaning is optional
   stable over time and appears only at will not change and that the end of a
      record, following a "number sign" ("#", %x23).
   o  The sequence '..' denotes a range choice of values.  Such a range
      represents all subtags language
   tag for specific content is also stable over time.

   These rules specifically deal with how changes to codes (including
   withdrawal and deprecation of the same length that codes) maintained by ISO 639, ISO
   15924, ISO 3166, and UN M.49 are alphabetically
      within that range, including reflected in the values explicitly mentioned.  For
      example 'a..c' denotes IANA Language
   Subtag Registry.  Assignments to the values 'a', 'b', and 'c'.

   The field 'type' IANA Language Subtag Registry
   MUST consist of one of follow the following strings:
   "language", "extlang", "script", "region", "variant",
   "grandfathered", and "redundant" and denotes the type of subtag (or
   tag, stability rules:

   o  Values in the case of "grandfathered" fields 'Type', 'Subtag', 'Tag', 'Added' and "redundant").

   The field 'subtag' contains
      'Canonical' MUST NOT be changed and are guaranteed to be stable
      over time.

   o  Values in the subtag being defined.

   The 'Description' field 'description' contains a description of the subtag
   transcribed into ASCII.

   Note: Descriptions MUST NOT be changed in registry entries a way
      that correspond would invalidate previously-existing tags.  They may be
      broadened somewhat in scope, changed to ISO 639,
   ISO 15924,  ISO 3166 add information, or UN M.49 codes are intended only
      adapted to indicate the meaning most common modern usage.  For example, countries
      occasionally change their official names: an historical example of that identifier as defined
      this would be "Upper Volta" changing to "Burkina Faso".

   o  Values in the source standard at
   the time it was field 'Recommended-Prefix' MAY be added to the registry.  The description does not
   replace via the content of
      registration process.

   o  Values in the source standard itself.  The descriptions
   are not intended to field 'Recommended-Prefix' MAY be modified, so long
      as the English localized names for modifications broaden the subtags
   and localization or translation of language tag and subtag
   descriptions is out set of scope recommended prefixes.
      That is, a recommended prefix MAY be replaced by one of this document.

   The field 'date' contains the date the record was added to its own
      prefixes.  For example, the
   registry in prefix "en-US" could be replaced by
      "en", but not by the "full-date" format specified in RFC 3339 [20].  For
   example: 2004-06-28 represents June 28, 2004, ranges "en-Latn", "fr", or "en-US-boont".

   o  Values in the Gregorian
   calendar.

   The field 'canonical value' represents a canonical mapping of this
   record to a subtag record of the same 'type', except for records of
   type "grandfathered" and "redundant".  This field SHALL 'Recommended-Prefix' MUST NOT be
   modified (except for records removed.

   o  The field 'Comments' MAY be added, changed, modified, or removed
      via the registration process or any of type "grandfathered"): therefore a
   subtag whose record contains no canonical mapping when the record is
   created is a canonical form and will remain so. processes or
      considerations described in this section.

   o  The 'canonical
   value' field in records 'Suppress-Script' MAY be added or removed via the
      registration process.

   o  Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do not
      conflict with existing subtags of the associated type "grandfathered" and "redundant"
   contain whole language tags that whose
      meaning is not the same as an existing subtag of the same type are STRONGLY RECOMMENDED
      entered into the IANA registry as new records and their value is
      canonical for use the meaning assigned to them.

   o  Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are
      withdrawn by their respective maintenance or registration
      authority remain valid in
   place language tags.  The registration process
      MAY be used to add a note indicating the withdrawal of the record's value.  In many cases code by
      the mappings were created respective standard.

   o  Codes assigned by deprecation ISO 639, ISO 15924, or ISO 3166 that do not
      conflict with existing subtags of the tags during the period before this document was
   adopted.  For example, associated type but which
      represent the tag "no-nyn" was deprecated in favor same meaning as an existing subtag of that type are
      entered into the ISO 639-1 defined language code 'nn'. IANA registry as new records.  The value "--" in the field
      'canonical value' field means for that record MUST contain the tag or existing subtag has been deprecated and that no replacement value has been
   assigned.  For example,
      of the "region" code 'BQ' (British Antarctic
   Territory) was withdrawn by same meaning

      Example If ISO 3166 were to assign the code 'IM' to represent the
         value "Isle of Man" (represented in 1979.  Although valid in
   language tags, it is deprecated the IANA registry by the UN
         M.49 code '833'), '833' remains the canonical subtag and validating processors SHOULD NOT
   generate this subtag.

   The field 'recommended prefix' is for use with 'IM'
         would be assigned '833' as a canonical value.  This prevents
         tags that are in canonical form from becoming non-canonical.

      Example If the tag 'enochian' were registered variants as a primary
         language subtag and contains ISO 639 subsequently assigned an alpha-3
         code to the same language, the new ISO 639 code would be
         entered into the IANA registry as a semicolon separated list of language-ranges considered
   most appropriate for use subtag with this subtag.  Additional values a canonical
         mapping to 'enochian'.  The new ISO code can be
   added to this field for variants only via additional registration.
   Other modification of this field (such as removing or changing
   values) used, but it is
         not permitted. canonical.

   o  Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict
      with existing subtags of the associated type MUST NOT be entered
      into the registry.  The field 'comments' may contain following additional information about considerations apply:

      *  For ISO 639 codes, if the
   subtag, newly assigned code's meaning is not
         represented by a subtag in the IANA registry, the Language
         Subtag Reviewer, as deemed appropriate described in Section 3.4, shall prepare a
         proposal for understanding entering in the IANA registry and
   implementing as soon as practical
         a registered language tags using subtag as an alternate value for the various subtags.  These values
   can new
         code.  The form of the registered language subtag will be changed via at
         the registration process and no guarantee discretion of
   stability is provided.

   # IANA the Language Subtag Registry
   # This registry lists Reviewer and must conform
         to other restrictions on language subtags in this document.

      *  For all valid subtags for language tags
   # created under RFC XXXX.
   date| 2004-08-07

   # language codes: ISO 639 and registered codes

   # whose meaning is derived from an external
         standard (i.e.  ISO 639-1 (alpha-2) codes
   language| aa| Afar| 2004-07-06| |
   language| ab| Abkhazian| 2004-07-06| |
   language| ae| Avestan| 2004-07-06| |
   language| he| hebrew| 2004-06-28| |
   language| iw| hebrew| 2004-06-28| he | #note mapping
   language| qaa..qtz| PRIVATE USE| 2004-07-06| |
   language| raj| Rajasthani| 2004-07-06| |
   language| seuss| Hypothetical Language| 2005-04-01 | |# registered language

   # script codes: 639, ISO 15924

   script| Arab| Arabic| 2004-07-06| |
   script| Armn| Armenian| 2004-07-06| |
   script| Bali| Balinese| 2004-07-06| |
   # region codes: 15924, ISO 3166 and 3166, or UN codes

   # ISO 3166-1 alpha-2 codes

   region| AA| PRIVATE USE| 2004-08-01| |
   region| AD| Andorra| 2004-07-06| |
   region| AE| United Arab Emirates| 2004-07-06| |
   region| AF| Afghanistan| 2004-07-06| |
   region| BQ| British Antarctic Territory | 2004-07-06 | -- | # deprecated 1979
   region| CS| Serbia and Montenegro| 2003-07-23| |
   region| YU| Yugoslavia| 2004-06-28| |

   # United Nations M.49 numeric codes
   region| 001| World| 2004-07-06| |
   region| 002| Africa| 2004-07-06| |
   region| 003| North America| 2004-07-06| |
   region| 005| South America| 2004-07-06| |
   region| 200| Czechoslovakia| 2004-07-06| | #formerly used M.49), if a
         new meaning is assigned to an existing code CS

   ## registered variants

   variant| boont| Boontling| 2003-02-14| | en
   variant| gaulish| Gaulish| 2001-05-25| | cel
   variant| guoyu| Mandarin or Standard Chinese| 1999-12-18| | zh

   # grandfathered from RFC 3066

   grandfathered| en-GB-oed| English, Oxford English Dictionary spelling| 2003-07-09| |
   grandfathered| i-ami| Amis| 1999-05-25| |
   grandfathered| i-bnn| Bunun| 1999-05-25| |
   grandfathered| art-lojban| Lojban| 2001-11-11|jbo |  # deprecated in favor and the new meaning
         broadens the meaning of 'jbo'

   # redundant
   # that code, then the meaning for the
         associated subtag MAY be changed to match.  The following codes were registered meaning of a
         subtag MUST NOT be narrowed, however, as complete tags, but this can now be
   # composed of registered subtags and do not require registration.

   redundant| az-Arab| Azerbaijani in Arabic script| 2003-05-30| |  # use language az + script Arab
   redundant| az-Cyrl| Azerbaijani result in Cyrillic script| 2003-05-30| |  # use language az + script Cyrl
   redundant| en-boont| Boontling| 2003-02-14| |  # use language en + variant boont

                Figure 2: Example an
         unknown proportion of the Registry Format

   Maintenance existing uses of a subtag becoming
         invalid.  Note: ISO 639 MA/RA has adopted a similar stability
         policy.

      *  For ISO 15924 codes, if the registry requires that as new codes are newly assigned code's meaning is
         not represented by ISO 639, ISO 15924, and ISO 3166, a subtag in the Language Subtag Reviewer
   will evaluate each assignment, determine whether it conflicts with
   existing registry entries, and submit the information to IANA for
   inclusion in the registry.

   Note: The redundant and grandfathered entries together are the
   complete list of tags registered under RFC 3066 [18].  The redundant
   tags are those that can now be formed using registry, the subtags defined Language
         Subtag Reviewer, as described in Section 2.2.  The grandfathered entries are those that can never be
   legal under those same provisions.  The items in both lists are
   permanent and stable, although grandfathered items may be deprecated
   over time.  Refer to Appendix C 3.4, shall prepare a
         proposal for more information.

   RFC 3066 tags that were deprecated prior to the adoption of this
   document are part of entering in the list of grandfathered tags and their
   component subtags were not included IANA registry as soon as practical
         a registered variants (although
   they remain eligible variant subtag as an alternate value for registration).  For example, the tag
   "art-lojban" was deprecated in favor new
         code.  The form of the language registered variant subtag 'jbo'.

   The will be at the
         discretion of the Language Subtag Reviewer MUST ensure that new and must conform to
         other restrictions on variant subtags meet the
   requirements in Section 2.3 or submit an appropriate alternate this document.

      *  For ISO 3166 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 described in the
         canonical entry for that section.  She or he will use region and no new entry is created.  A
         comment MAY be added to the following form existing region subtag indicating
         the relationship to submit this information:

   LANGUAGE SUBTAG REGISTRATION FORM (NEW RECORD)
   Record Text:
   Type:
   Subtag:
   Description:
   Date:
   Canonical Mapping:
   Recommended Prefix:
   Comments:

                                Figure 3

   The field 'record text' contains the exact record new ISO 3166 code.

      *  For ISO 3166 codes, if the newly assigned code's meaning is
         associated with a UN M.49 code that IANA is to
   insert into not represented by an
         existing region subtag, then then the Language Subtag Registry.  The contents of the
   remaining fields must exactly match those Reviewer,
         as described in this field.

   Whenever Section 3.4, shall prepare a proposal for
         entering the appropriate numeric UN country code as an entry is created or modified in
         the registry, IANA registry.

      *  For ISO 3166 codes, if there is no associated UN numeric code,
         then the 'date'
   record at Language Subtag Reviewer SHALL petition the start UN to
         create one.  If there is no response from the UN within ninety
         days of the registry is updated to reflect request being sent, the most
   recent modification date Language Subtag Reviewer
         shall prepare a proposal for entering in the RFC 3339 [20] "full-date" format.

3.2  Stability of IANA Registry Entries registry as
         soon as practical a registered variant subtag as an alternate
         value for the new code.  The stability form of entries and their meaning in the registry is
   critical to registered variant
         subtag will be at the long term stability discretion of language tags.  The rules the Language Subtag
         Reviewer and must conform to other restrictions on variant
         subtags in this section guarantee that a specific language tag's meaning is
   stable over time and will not change and that the choice of language
   tag for specific content document.  This situation is also stable over time.

   These rules specifically deal with how changes very unlikely to codes (including
   withdrawal and deprecation
         ever occur.

   o  Stability provisions apply to grandfathered tags with this
      exception: should all of codes) maintained by ISO 639, ISO
   15924, ISO 3166, and UN M.49 are reflected the subtags in a grandfathered tag become
      valid subtags in the IANA Language
   Subtag Registry.  Assignments to registry, then the IANA Language Subtag Registry grandfathered tag
      MUST follow be marked as redundant.  Note that this will not affect
      language tags that match the following stability rules:
   o  Values grandfathered tag, since these tags
      will now match valid generative subtag sequences.  For example, if
      the subtag 'gan' in the fields 'type', 'subtag', 'date' and 'canonical
      value' MUST NOT be changed and are guaranteed language tag "zh-gan" were to be stable over
      time.
   o  Values in
      registered as an extended language subtag, then the 'description' field MUST NOT be changed in a way
      that grandfathered
      tag "zh-gan" would invalidate previously-existing tags.  They may be
      broadened somewhat in scope, changed to add information, deprecated (but existing content or
      adapted to the most common modern usage.  For example, countries
      occasionally change their official names: an historical example of
      this
      implementations that use "zh-gan" would remain valid).

3.4  Registration Procedure for Subtags

   The procedure given here MUST be "Upper Volta" changing used by anyone who wants to "Burkina Faso".
   o  Values use a
   subtag not currently in the field 'recommended prefix' MAY IANA Language Subtag Registry.

   Only subtags  of type 'language' and 'variant' will be added via the considered for
   independent registration process.
   o  Values in the field 'recommended prefix' MAY be modified, so long
      as the modifications broaden the set of recommended prefixes.
      That is, a recommended prefix MAY be replaced by one new subtags.  Handling of its own
      prefixes.  For example, the prefix "en-US" could be replaced by
      "en", but not by the ranges "en-Latn", "fr", or "en-US-boont".
   o  Values in the field 'recommended prefix' MUST NOT be removed.
   o  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.
   o  Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do not
      conflict with existing subtags of the associated type
   required for stability and whose
      meaning is not the same as an existing subtag of the same type are
      entered into subtags required to keep the IANA registry as new records and their value is
      canonical for the meaning assigned to them.
   o  Codes assigned by
   synchronized with ISO 639, ISO 15924, or ISO 3166 that are
      withdrawn 3166, and UN M.49 within
   the limits defined by their respective maintenance or registration
      authority remain valid this document are described in language tags.  The registration process Section 3.2.
   Stability provisions are described in Section 3.3.

   This procedure MAY also be used to add a note indicating the withdrawal of the code by
      the respective standard.
   o  Codes assigned by ISO 639, ISO 15924, register or ISO 3166 that do not
      conflict with existing subtags of alter the associated type but which
      represent information
   for the same meaning "Description", "Comments", "Deprecated", or "Recommended-
   Prefix" fields in a subtag's record as an existing subtag of that type are
      entered into described in Figure 7.
   Changes to all other fields in the IANA registry as are NOT permitted.

   Registering a new records.  The field
      'canonical value' for that record MUST contain the subtag or requesting modifications to an existing
   tag or subtag
      of starts with the same meaning
      Example If ISO 3166 were to assign requster filling out the code 'IM' registration
   form reproduced below.  Note that each response is not limited in
   size and should take the room necessary to represent adequately describe the
         value "Isle of Man" (represented
   registration.  The fields in the IANA registry by "Record Requested" section SHOULD
   follow the UN
         M.49 code '833'), '833' remains requirements in Section 3.1.

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

   Type:
   Subtag:
   Description:
   Recommended-Prefix:
   Canonical:
   Deprecated:
   Suppress-Script:
   Comments:

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

                                 Figure 5

   The subtag and 'IM'
         would registration form MUST be assigned '833' as sent to
   <ietf-languages@iana.org> for a canonical value.  This prevents
         tags that two week review period before it can
   be submitted to IANA.  (This is an open list.  Requests to be added
   should be sent to <ietf-languages-request@iana.org>.)

   Variant subtags are in canonical form from becoming non-canonical.

      Example If the tag 'enochian' were generally registered as for use with a primary particular
   range of language subtag and ISO 639 subsequently assigned an alpha-3
         code to the same language, the new ISO 639 code would be
         entered into tags.  For example, the IANA registry as a subtag with a canonical
         mapping to 'enochian'.  The new ISO code can be used, but it 'scouse' is
         not canonical.
   o  Codes assigned by ISO 639, ISO 15924, or ISO 3166 intended
   for use with language tags that conflict start with existing subtags the primary language
   subtag "en", since Scouse is a dialect of English.  Thus the associated type MUST NOT subtag
   'scouse' could be entered
      into the registry.  The following additional considerations apply:
      *  For ISO 639 codes, if the newly assigned code's meaning included in tags such as "en-Latn-scouse" or "en-
   GB-scouse".  This information is not
         represented by a subtag stored in the IANA registry, the Language
         Subtag Reviewer, as described "Recommended-Prefix"
   field in Section 3.3, shall prepare a
         proposal for entering the registry.  Variant registration requests are REQUIRED to
   include at least one "Recommended-Prefix" field in the IANA registry as soon as practical registration
   form.

   Any subtag MAY be incorporated into a registered variety of language subtag as an alternate value for tags,
   according to the new
         code.  The form rules of Section 2.1, including tags that do not
   match any of the registered language subtag will be at
         the discretion recommended prefixes of the Language Subtag Reviewer and must conform
         to other restrictions on language subtags in registered subtag.
   (Note that this document.
      *  For all subtags whose meaning is derived from an external
         standard (i.e.  ISO 639, ISO 15924, ISO 3166, or UN M.49), if probably a
         new meaning is assigned to an existing code poor choice.)  This makes validation
   simpler and thus more uniform across implementations, and does not
   require the new meaning
         broadens the meaning registration of that code, then the meaning a separate subtag for the
         associated subtag MAY be changed to match.  The same purpose
   and meaning of but a different recommended prefix.

   The recommended prefixes for a given registered subtag MUST NOT will be narrowed, however, as this can result
   maintained in an
         unknown proportion of the existing uses of a subtag becoming
         invalid.  Note: ISO 639 MA/RA has adopted IANA registry as a similar stability
         policy.
      *  For ISO 15924 codes, if the newly assigned code's meaning is
         not represented guide to usage.  If it is
   necessary to add an additional prefix to that list for an existing
   language tag, that can be done by a subtag in filing an additional registration
   form.  In that form, the IANA registry, "Any other relevant information:" field
   should indicate that it is the Language
         Subtag Reviewer, as described in Section 3.3, shall prepare addition of an additional recommended
   prefix.

   Requests to add a
         proposal for entering in the IANA registry as soon as practical recommended prefix to a registered variant subtag as an alternate value for that imply a
   different semantic meaning will probably be rejected.  For example, a
   request to add the new
         code.  The form of prefix "de" to the registered variant subtag will 'nedis' so that the tag
   "de-nedis" represented some German dialect would be at rejected.  The
   'nedis' subtag represents a particular Slovenian dialect and the
         discretion of
   additional registration would change the Language Subtag Reviewer and must conform semantic meaning assigned to
         other restrictions on variant subtags in this document.
      *  For ISO 3166 codes, if
   the newly assigned code's meaning is
         associated with subtag.  A separate subtag should be proposed instead.

   The 'Description' field must contain a description of the same UN M.49 code as another 'region'
         subtag, then tag being
   registered written or transcribed into the existing region subtag remains as Latin script; it may also
   include a description in a non-Latin script.  Non-ASCII characters
   must be escaped using the
         canonical entry syntax described in Section 3.1.  The
   'Description' field is used for that region identification purposes and no new entry is created.  A
         note MAY should
   not be added taken to represent the existing region subtag indicating actual native name of the
         relationship language or
   variation or to be in any particular language.

   While the new ISO 3166 code.
      *  For ISO 3166 codes, if the newly assigned code's meaning is
         associated with a UN M.49 code that 'Description' field itself is not represented guaranteed to be stable
   and errata corrections may be undertaken from time to time, attempts
   to provide translations or transcriptions of entries in the registry
   itself will probably be frowned upon by an
         existing region subtag, then then the Language Subtag Reviewer, community or rejected
   outright, as described in Section 3.3, shall prepare a proposal for
         entering changes of this nature may impact the appropriate numeric UN country code as an entry provisions in
         the IANA registry.
      *  For ISO 3166 codes, if there is no associated UN numeric code,
         then the
   Section 3.3.

   The Language Subtag Reviewer SHALL petition the UN to
         create one.  If there is no response from the UN within ninety
         days of the request being sent, the Language Subtag Reviewer
         shall prepare a proposal responsible for entering in the IANA registry as
         soon as practical a registered variant subtag as an alternate
         value responding to
   requests for the new code.  The form registration of subtags through the registered variant
         subtag will be at registration
   process  and is appointed by the discretion of IESG.

   When the two week period has passed the Language Subtag Reviewer and must conform
   either forwards the record to other restrictions on variant
         subtags in this document.  This situation is very unlikely be inserted or modified to
         ever occur.
   o  Stability provisions apply
   iana@iana.org according to grandfathered tags with this
      exception: should all of the subtags in a grandfathered tag become
      valid subtags procedure described in Section 3.2, or
   rejects the IANA registry, then the grandfathered tag
      MUST be marked as redundant.  Note that this will not affect
      language tags that match the grandfathered tag, since these tags
      will now match valid generative subtag sequences.  For example, if request because of significant objections raised on the subtag 'gan'
   list or due to problems with constraints in this document (which
   should be explicitly cited).  The reviewer may also extend the language tag "zh-gan" were review
   period in two week increments to be
      registered as an extended language subtag, then permit further discussion.  The
   reviewer must indicate on the grandfathered
      tag "zh-gan" would be deprecated (but existing content list whether the registration has been
   accepted, rejected, or
      implementations that use "zh-gan" would remain valid).

   Language tags formed under RFC 3066 extended following each two week period.

   Note that use the region subtag 'CS'
   were ambiguous, since tags produced before 2003 used reviewer can raise objections on the list if he or she
   so desires.  The important thing is that code for the (now dissolved) country Czechoslovakia.  ISO 3166 assigned this
   code objection must be made
   publicly.

   The applicant is free to the country Serbia and Montenegro in 2003 modify a rejected application with
   additional information and submit it again; this draft
   makes that restarts the canonical value for this subtag.  To form a language
   tag for two
   week comment period.

   Decisions made by the region Czechoslovakia, reviewer may be appealed to the UN M.49 code '200' is included
   in IESG [RFC 2028]
   [9] under the registry.  As a practical matter, applications that encounter same rules as other IETF decisions [RFC 2026] [8].

   All approved registration forms are available online in the RFC 3066 tag "cs-CS" directory
   http://www.iana.org/numbers.html under "languages".

   Updates or "sk-CS" MAY wish to convert that changes to
   "cs-200" or "sk-200" (or use one of existing records, including previous
   registrations, follow the successor region subtags,
   such same procedure as 'CZ' or 'SK'), since that new registrations.  The
   Language Subtag Reviewer decides whether there is consensus to update
   the most likely interpretation.

3.3  Registration Procedure for Subtags

   The procedure given here MUST be used registration following the two week review period; normally
   objections by anyone who wants to use a
   subtag not currently in the IANA Language Subtag Registry.

   Only primary language original registrant will carry extra weight in
   forming such a consensus.

   Registrations are permanent and variant stable.  Once registered, subtags
   will not be considered for
   independent registration.  (Subtags required for stability and
   subtags required to keep removed from the registry synchronized with ISO 639, ISO
   15924, ISO 3166, and UN M.49 within the limits defined by this
   document are will remain the only exceptions canonical
   method of referring to this.  See Section 3.2.) a specific language or variant.  This procedure MAY also be used
   provision does not apply to register or alter the information
   for the "description", "note", or "recommended prefix" fields in a
   subtag's record as described in Figure 2.  Changes grandfathered tags, which may become
   deprecated due to all other
   fields registration of subtags.  For example, the tag
   "i-navajo" is deprecated in favor of the IANA registry are NOT permitted.

   If registering a new language subtag, ISO 639-1 based subtag 'nv'.

   Note: The purpose of the process starts by filling
   out "published description" in the registration
   form reproduced below.  Note that each response is not limited in size and should take the room necessary intended as an aid to
   adequately describe the registration.

   LANGUAGE SUBTAG REGISTRATION FORM
   1. Name of requester:
   2. E-mail address of requester:
   3. Subtag people trying to be registered:
   4. Type of Registration:
      [ ] verify whether a
   language
      [ ] variant
   5. Description of subtag (in English is registered or transcribed into ASCII):
   6. Intended meaning of the subtag:
   7. Recommended prefix(es) of subtag (for variants):
   8. Native name of the what language or variation (transcribed into ASCII):
   9. Reference to published description of the language (book or article):
   10. Any other relevant information:

                                Figure 4

   The subtag registration form MUST be sent to
   <ietf-languages@iana.org> for variation a two week review period before it can
   be submitted
   particular subtag refers to.  In most cases, reference to IANA.  (This is an open list.  Requests to be added
   should be sent to <ietf-languages-request@iana.org>.)

   Variant subtags are generally registered for use with a particular
   range
   authoritative grammar or dictionary of language tags.  For example, the subtag 'boont' is intended
   for use with language tags that start with the primary language
   subtag "en", since Boontling is a dialect of English.  Thus the
   subtag 'boont' could will be included useful;
   in tags cases where no such as "en-Latn-boont" work exists, other well known works describing
   that language or
   "en-US-boont". in that language may be appropriate.  The subtag
   reviewer decides what constitutes "good enough" reference material.
   This information requirement is stored in not intended to exclude particular languages or
   dialects due to the "recommended
   prefix" field in size of the registry and MUST speaker population or lack of a
   standardized orthography.  Minority languages will be provided in the considered
   equally on their own merits.

3.5  Possibilities for Registration

   Possibilities for registration form.

   Any subtag MAY be incorporated into a variety of subtags or information about
   subtags include:

   o  Primary language tags,
   according to the rules of Section 2.1, including tags subtags for languages not listed in ISO 639 that do
      are not
   match any variants of the recommended prefixes any listed or registered language can be
      registered.  At the time this document was created there were no
      examples of this form of subtag.  Before attempting to register a
      language subtag, there MUST be an attempt to register the language
      with ISO 639.  No language subtags will be registered subtag.
   (Note for codes
      that this is probably a poor choice.) This makes validation
   simpler and thus more uniform across implementations, and does not
   require exist in ISO 639-1 or ISO 639-2, which are under
      consideration by the ISO 639 maintenance or registration of a separate subtag
      authorities, or which have never been attempted for the same purpose
   and meaning but registration
      with those authorities.  If ISO 639 has previously rejected a different recommended prefix.

   The recommended prefixes
      language for a given registered subtag registration, it is reasonable to assume that there
      MUST be additional very compelling evidence of need before it will
      be
   maintained registered in the IANA registry as a guide to usage.  If (to the extent that it is
   necessary to add an additional prefix to that list for an existing
   language tag, very
      unlikely that can any subtags will be done by filing an additional registration
   form.  In that form, the "Any registered of this type).

   o  Dialect or other relevant information:" field
   should indicate that it divisions or variations within a language, its
      orthography, writing system, regional or historical usage,
      transliteration or other transformation, or distinguishing
      variation may be registered as variant subtags.  An example is the
      'scouse' subtag (the Scouse dialect of English).

   o  The addition or maintenance of fields (generally of an additional recommended
   prefix.

   Requests
      informational nature) in Tag or Subtag records as described in
      Section 3.1 and subject to add a recommended prefix to a subtag that imply a
   different semantic meaning will probably be rejected.  For example, a
   request to add the prefix "de" to the subtag 'nedis' so that the tag
   "de-nedis" represented some German dialect would be rejected.  The
   'nedis' subtag represents a particular Slovenian dialect and the
   additional registration would change stability provisions in
      Section 3.3.  This includes descriptions, recommended prefixes,
      comments, deprecation of obsolete items, or the semantic meaning assigned addition of script
      or extlang information to primary language subtags.

   This document leaves the subtag.  A separate subtag should be proposed instead.

   The Language Subtag Reviewer is responsible for responding decision on what subtags  or changes to
   requests for the registration of
   subtags through are appropriate (or not) to the registration process  and is appointed by the IESG.

   When the two week period has passed the Language Subtag Reviewer
   either forwards the request
   described in Section 3.4.

   Note: four character primary language subtags are reserved to iana@iana.org, or rejects it because allow
   for the possibility of significant objections raised on  alpha4 codes in some future addition to the list or due
   ISO 639 family of standards.

   ISO 639 defines a maintenance agency for additions to problems with
   constraints and changes in this document (which should be explicitly cited).  The
   reviewer may also extend
   the review period list of languages in two week increments ISO 639.  This agency is:

   International Information Centre for Terminology (Infoterm)
    Aichholzgasse 6/12, AT-1120
   Wien, Austria
   Phone: +43 1 26 75 35 Ext. 312 Fax: +43 1 216 32 72

   ISO 639-2 defines a maintenance agency for additions to
   permit further discussion.  The reviewer must indicate on and changes
   in the list
   whether the registration has been accepted, rejected, of languages in ISO 639-2.  This agency is:

   Library of Congress
   Network Development and MARC Standards Office
   Washington, D.C. 20540 USA
   Phone: +1 202 707 6237  Fax: +1 202 707 0115
   URL: http://www.loc.gov/standards/iso639

   The maintenance agency for ISO 3166 (country codes) is:

   ISO 3166 Maintenance Agency
   c/o International Organization for Standardization
   Case postale 56
   CH-1211 Geneva 20 Switzerland
   Phone: +41 22 749 72 33  Fax: +41 22 749 73 49
   URL: http://www.iso.org/iso/en/prods-services/iso3166ma/index.html

   The registration authority for ISO 15924 (script codes) is:

   Unicode Consortium Box 391476
   Mountain View, CA 94039-1476, USA
   URL: http://www.unicode.org/iso15924

   The Statistics Division of the United Nations Secretariat maintains
   the Standard Country or Area Codes for Statistical Use and can be
   reached at:

   Statistical Services Branch
   Statistics Division
   United Nations, Room DC2-1620
   New York, NY 10017, USA

   Fax: +1-212-963-0623
   E-mail: statistics@un.org
   URL: http://unstats.un.org/unsd/methods/m49/m49alpha.htm

3.6  Extensions and Extensions Namespace

   Extension subtags are those introduced by single-letter subtags other
   than 'x-'.  They are reserved for the generation of identifiers which
   contain a language component, and are compatible with applications
   understand language tags.  For example, they might be used to define
   locale identifiers, which are generally based on language.

   The structure and form of extensions are defined by this document so
   that implementations can be created that are forward compatible with
   applications that may be created using single-letter subtags in the
   future.  In addition, defining a mechanism for maintaining single-
   letter subtags will lend to the stability of this document by
   reducing the likely need for future revisions or updates.

   Allocation of a single-letter subtag shall take the form of an RFC
   defining the name, purpose, processes, and procedures for maintaining
   the subtags.  The maintaining or registering authority, including
   name, contact email, discussion list email, and URL location of the
   registry must be indicated clearly in the RFC.  The RFC MUST specify
   or include each of the following:

   o  The specification MUST reference the specific version or revision
      of this document that governs its creation and MUST reference this
      section of this document.

   o  The specification and all subtags defined by the specification
      MUST follow the ABNF and other rules for the formation of tags and
      subtags as defined in this document.  In particular it MUST
      specify that case is not significant and that subtags MUST NOT
      exceed eight characters in length.

   o  The specification MUST specify a canonical representation.

   o  The specification of valid subtags MUST be available over the
      Internet and at no cost.

   o  The specification MUST be in the public domain or available via a
      royalty-free license acceptable to the IETF and specified in the
      RFC.

   o  The specification MUST be versioned and each version of the
      specification MUST be numbered, dated, and stable.

   o  The specification MUST be stable.  That is, extension subtags,
      once defined by a specification, MUST NOT be retracted or change
      in meaning in any substantial way.

   o  The specification MUST include in a separate section the
      registration form reproduced in this section (below) to be used in
      registering the extension upon publication as an RFC.

   o  IANA MUST be informed of changes to the contact information and
      URL for the specification.

   IANA will maintain a registry of allocated single-letter (singleton)
   subtags.  This registry will use the record-jar format described by
   the ABNF in Section 3.1.  Upon publication of an extension as an RFC,
   the maintaining authority defined in the RFC must forward this
   registration form to iesg@ietf.org, who will forward the request to
   iana@iana.org.  The maintaining authority of the extension MUST
   maintain the accuracy of the record by sending an updated full copy
   of the record to iana@iana.org with the subject line "LANGUAGE TAG
   EXTENSION UPDATE" whenever content changes.  Only the 'Comments',
   'Contact_Email', 'Mailing_List', and 'URL' fields may be modified in
   these updates.

   Failure to maintain this record, the corresponding registry, or meet
   other conditions imposed by this section of this document may be
   appealed to the IESG [RFC 2028] [9] under the same rules as other
   IETF decisions (see [8]) and may result in the authority to maintain
   the extension being withdrawn or reassigned by the IESG.
   %%
   Identifier:
   Description:
   Comments:
   Added:
   RFC:
   Authority:
   Contact_Email:
   Mailing_List:
   URL:
   %%

    Figure 6: Format of Records in the Language Tag Extensions Registry

   'Identifier' contains the single letter subtag (singleton) assigned
   to the extension.  The Internet-Draft submitted to define the
   extension should specific which letter to use, although the IESG may
   change the assignment when approving the RFC.

   'Description' contains the name and description of the extension.

   'Comments' is an optional field and may contain a broader description
   of the extension.

   'Added' contains the date the RFC was published in the "full-date"
   format specified in RFC 3339 [14].  For example: 2004-06-28
   represents June 28, 2004, in the Gregorian calendar.

   'RFC' contains the RFC number assigned to the extension.

   'Authority' contains the name of the maintaining authority for the
   extension.

   'Contact_Email' contains the email address used to contact the
   maintaining authority.

   'Mailing_List' contains the URL or subscription email address of the
   mailing list used by the maintaining authority.

   'URL' contains the URL of the registry for this extension.

   The determination of whether an Internet-Draft meets the above
   conditions and the decision to grant or withhold such authority rests
   solely with the IESG, and is subject to the normal review and appeals
   process associated with the RFC process.

   Extension authors are strongly cautioned that many (including most
   well-formed) processors will be unaware of any special relationships
   or meaning inherent in the order of extension subtags.  Extension
   authors SHOULD avoid subtag relationships or canonicalization
   mechanisms that interfere with matching or with length restrictions
   that may exist in common protocols where the extension is used.  In
   particular, applications may truncate the subtags in doing matching
   or in fitting into limited lengths, so it is RECOMMENDED that the
   most significant information be in the most significant (left-most)
   subtags, and that the specification gracefully handle truncated
   subtags.

   When a language tag is to be used in a specific, known, protocol, it
   is RECOMMENDED that that the language tag not contain extensions not
   supported by that protocol.  In addition, it should be noted that
   some protocols may impose upper limits on the length of the strings
   used to store or transport the language tag.

3.7  Conversion of the RFC 3066 Language Tag Registry

   Upon publication of this document as a BCP, the existing IANA
   language tag registry must be converted into the new subtag registry.
   This section defines the process for performing this conversion.

   The impact on the IANA maintainers of the registry of this conversion
   will be a small increase in the frequency of new entries.  The
   initial set of records represents no impact on IANA, since the work
   to create it will be performed externally (as defined in this
   section).  Future work will be limited to inserting or replacing
   whole records preformatted for IANA by the Language Subtag Reviewer.

   When this document is published, an email will be sent by the
   chair(s) of the LTRU working group to the LTRU and ietf-languages
   mail lists advising of the impending conversion of the registry.  In
   that notice, the chair(s) will provide a URL whose referred content
   is the proposed IANA Language Subtag Registry following conversion.
   There will be a Last Call period of not less than four weeks for
   comments and corrections to be discussed on the
   ietf-languages@iana.org mail list.  Changes as a result of comments
   will not restart the Last Call period.  At the end of the period, the
   chair(s) will forward the URL to IANA, which will post the new
   registry on-line.

   Tags that are currently deprecated will be maintained as
   grandfathered entries.  The record for the grandfathered entry will
   contain a 'Deprecated' field with the most appropriate date that can
   be determined for when the record was deprecated.  The 'Comments'
   field will contain the reason for the deprecation.  The 'Canonical'
   field will contain the tag that replaces the value.  For example, the
   tag "art-lojban" is deprecated and will be placed in the
   grandfathered section.  It's 'Deprecated' field will contain the
   deprecation date and 'Canonical' field the value "jbo".

   Tags that are not deprecated that consist entirely of subtags that
   are valid under this document and which have the correct form and
   format for tags defined by this document are superseded by this
   document.  Such tags are placed in records of type 'redundant' in the
   registry.  For example, "zh-Hant" is now defined by this document.

   Tags that are not deprecated and which contain subtags which are
   consistent with registration under the guidelines in this document
   will have a new subtag registration created for each eligible subtag.
   If all of the subtags in the original tag are fully defined by the
   resulting registrations or by this document, then the original tag is
   superseded by this document.  Such tags are placed in the 'redundant'
   section of the registry.  For example, "en-boont" will result in a
   new subtag 'boont' and the RFC 3066 registered tag "en-boont" placed
   in the redundant section of the registry.

   Tags that contain one or more subtags that do not match the valid
   registration pattern and which are not otherwise defined by this
   document will have records of type  'grandfathered' created in the
   registry.

   There will be a reasonable period in which the community may comment
   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
   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
   publication.

   Registrations that are in process under the rules defined in RFC 3066
   MAY be completed under the former rules, at the discretion of the
   language tag reviewer.  Any new registrations submitted after the
   request for conversion of the registry MUST be rejected.

   All existing RFC 3066 language tag registrations will be maintained
   in perpetuity.

   Users of tags that are grandfathered should consider registering
   appropriate subtags in the IANA subtag registry (but are not required
   to).

   Where two subtags have the same meaning, the priority of which to
   make canonical SHALL be the following:

   o  As of the date of acceptance of this document as a BCP, if a code
      exists in the associated ISO standard and it is not deprecated or extended
      withdrawn as of that date, then it has priority.

   o  Otherwise, the earlier-registered tag in the associated ISO
      standard has priority.

   UN numeric codes assigned to 'macro-geographical (continental)' or
   sub-regions not associated with an assigned ISO 3166 alpha-2 code are
   defined in the IANA registry and are valid for use in language tags.
   These codes MUST be added to the initial version of the registry.
   The UN numeric codes for 'economic groupings' or 'other groupings',
   and the alphanumeric codes in Appendix X of the UN document MUST NOT
   be added to the registry.

   When creating records for ISO 639, ISO 15924, ISO3166, and UN M.49
   codes, the following criteria SHALL be applied to the inclusion,
   canonical mapping, and deprecation of codes:

   For each two week period.

   Note standard, the date of the standard referenced in RFC 1766 is
   selected as the starting date.  Codes that were valid on that date in
   the selected standard are added to the registry.  Codes that were
   previously assigned by were vacated or withdrawn before that date are
   not added to the registry.  For each successive change to the
   standard, any additional assignments are added to the registry.
   Values that are withdrawn are marked as deprecated, but not removed.
   Changes in meaning or assignment of a subtag are permitted during
   this process (cf. 'CS').  This continues up to the date that this
   document was adopted.  The resulting set of records is added to the
   registry.  Future changes or additions to this portion of the
   registry are governed by the provisions of this document.

4.  Formation and Processing of Language Tags

   This section addresses how to use the registry with the language tag
   format to choose, form and process language tags.

4.1  Choice of Language Tag

   One may occasionally be faced with several possible tags for the same
   body of text.

   Interoperability is best served when all users use the same language
   tag in order to represent the same language.  If an application has
   requirements that make the reviewer rules here inapplicable, then that
   application risks damaging interoperability.  It is strongly
   RECOMMENDED that users not define their own rules for language tag
   choice.

   Of particular note, many applications can raise objections on benefit from the use of
   script subtags in language tags, as long as the use is consistent for
   a given context.  Script subtags were not formally defined in RFC
   3066 and their use may affect matching and subtag identification by
   implementations of RFC 3066, as these subtags appear between the
   primary language and region subtags.  For example, if a user requests
   content in an implementation of Section 2.5 of RFC 3066 [23] using
   the language range "en-US", content labeled "en-Latn-US" will not
   match the request.  Therefore it is important to know when script
   subtags will customarily be used and when they should not be used.

   Extended language subtags (type 'extlang' in the registry, see
   Section 3.1) also appear between the primary language and region
   subtags and are reserved for future standardization.  Applications
   may benefit from their judicious use in forming language tags in the
   future and similar recommendations are expected to apply to their use
   as apply to script subtags.

   Standards, protocols and applications that reference this document
   normatively but apply different rules to the ones given in this
   section MUST specify how the list if he or she
   so desires.  The important thing is that procedure varies from the objection must be made
   publicly. one given
   here.

   The applicant is free choice of subtags used to modify form a rejected application with
   additional information and submit it again; this restarts the two
   week comment period.

   Decisions made language tag should be guided by
   the reviewer may following rules:

   1.  Use as precise a tag as possible, but no more specific than is
       justified.  Avoid using subtags that are not important for
       distinguishing content in an application.

       *  For example, 'de' might suffice for tagging an email written
          in German, while "de-CH-1996" is probably unnecessarily
          precise for such a task.

   2.  The script subtag SHOULD NOT be appealed used to form language tags unless
       the IESG [RFC 2028]
   [10] under script adds some distinguishing information to the same rules as other IETF decisions [RFC 2026] [21].

   All approved registration forms are available online tag.  The
       field 'Suppress-Script' in the directory
   http://www.iana.org/numbers.html under "languages".

   Updates of registrations follow primary language record in the
       registry indicates which script subtags do not add distinguishing
       information for most applications.

       *  For example, the same procedure as registrations.
   The subtag reviewer decides whether to allow 'Latn' should not be used with the
          primary language 'en' because nearly all English documents are
          written in the Latin script and it adds no distinguishing
          information.  However, if a new registrant document were written in English
          mixing Latin script with another script such as Braille
          ('Brai'), then it may be appropriate to
   update a registration made by someone else; normally objections by
   the original registrant would carry extra weight choose to indicate
          both scripts to aid in content selection, such a decision.

   Registrations are permanent and stable.  Once registered, subtags
   will not be removed from as the
          application of a stylesheet.

   3.  If a subtag has a 'Canonical' field in its registry and will remain entry, the
       canonical
   method of referring subtag SHOULD be used to a specific form the language or variant.  This
   provision does not apply to grandfathered tags, which may become
   deprecated due tag in
       preference to registration any of subtags. its aliases.

       *  For example, use 'he' for Hebrew in preference to 'iw'.

   4.  The 'und' (Undetermined) primary language subtag SHOULD NOT be
       used to label content, even if the language is unknown.  Omitting
       the language tag
   "i-navajo" altogether is deprecated in favor preferred to using a tag with a
       primary language subtag of the ISO 639-1 based 'und'.  The 'und' subtag 'nv'.

   Note: may be useful
       for protocols that require a language tag to be provided.  The purpose of the "published description"
       'und' subtag may also be useful when matching language tags in
       certain situations.

   5.  The 'mul' (Multiple) primary language subtag SHOULD NOT be used
       whenever the registration
   form is intended protocol allows the separate tags for multiple
       languages, as an aid to people trying is the case for the Content-Language header in
       HTTP.  The 'mul' subtag conveys little useful information:
       content in multiple languages should individually tag the
       languages where they appear or otherwise indicate the actual
       language in preference to verify whether the 'mul' subtag.

   6.  The same variant subtag SHOULD NOT be used more than once within
       a language is registered or what tag.

       *  For example, do not use "en-GB-scouse-scouse".

   To ensure consistent backward compatibility, this document contains
   several provisions to account for potential instability in the
   standards used to define the subtags that make up language or tags.
   These provisions mean that no language variation a
   particular subtag refers to. tag created under the rules in
   this document will become obsolete.  In most cases, reference to an
   authoritative grammar or dictionary of addition, tags that language are in
   canonical form will always be useful; in cases where no such work exists, other well known works describing
   that canonical form.

4.2  Meaning of the Language Tag

   The language tag always defines a language as spoken (or written,
   signed or in that otherwise signaled) by human beings for communication of
   information to other human beings.  Computer languages such as
   programming languages are explicitly excluded.

   If a language may be appropriate.  The subtag
   reviewer decides what constitutes "good enough" reference material. tag B contains language tag A as a prefix, then B is
   typically "narrower" or "more specific" than A. For example, "zh-
   Hant-TW" is more specific than "zh-Hant".

   This requirement relationship is not intended to exclude particular guaranteed in all cases: specifically,
   languages or
   dialects due to the size of that begin with the speaker population or lack same sequence of a
   standardized orthography.  Minority languages will be considered
   equally on their own merits.

3.4  Extensions and Extensions Namespace

   Extension subtags are those introduced by single-letter subtags other
   than 'x-'.  They are reserved for NOT
   guaranteed to be mutually intelligible, although they may be.  For
   example, the generation of identifiers which
   contain tag "az" shares a language component, and are compatible prefix with applications
   that process language tags according both "az-Latn"
   (Azerbaijani written using the Latin script) and "az-Cyrl"
   (Azerbaijani written using the Cyrillic script).  A person fluent in
   one script may not be able to this specification.  For
   example, they read the other, even though the text
   might be used identical.  Content tagged as "az" most probably is written
   in just one script and thus might not be intelligible to define locale identifiers, which are
   generally based on language. a reader
   familiar with the other script.

   The structure relationship between the tag and form of extensions are the information it relates to is
   defined by this document so
   that implementations can be created that are forward compatible with
   applications that may be created using single-letter subtags in the
   future.  In addition, defining a mechanism for maintaining
   single-letter subtags will lend to standard describing the stability of context in which it appears.
   Accordingly, this document by
   reducing the likely need for future revisions or updates.

   IANA will maintain a registry section can only give possible examples of allocated single-letter subtags.
   This registry contains the following information: letter identifier;
   name; purpose; RFC defining the subtag namespace and its use; and
   usage.

   o  For a single information object, the
   name, URL, and email address of associated language tags
      might be interpreted as the maintaining authority.

   Allocation set of languages that is required for
      a single-letter subtag shall take the form complete comprehension of the complete object.  Example: Plain
      text documents.

   o  For an RFC
   defining aggregation of information objects, the name, purpose, processes, and procedures for maintaining associated language
      tags could be taken as the subtags.  The maintaining or registering authority, including
   name, contact email, discussion list email, and URL location set of languages used inside components
      of that aggregation.  Examples: Document stores and libraries.

   o  For information objects whose purpose is to provide alternatives,
      the
   registry must associated language tags could be indicated clearly in regarded as a hint that the RFC.  The RFC MUST specify
      content is provided in several languages, and that one has to
      inspect each of the following:
   o  The specification MUST reference the specific version alternatives in order to find its language or revision
      of
      languages.  In this document case, the presence of multiple tags might not
      mean that govern its creation and MUST reference this
      section one needs to be multi-lingual to get complete
      understanding of this the document.  Example: MIME multipart/
      alternative.

   o  The specification  In markup languages, such as HTML and all subtags defined XML, language information
      can be added to each part of the document identified by the specification
      MUST follow markup
      structure (including the ABNF and other rules for whole document itself).  For example, one
      could write <span lang="fr">C'est la vie.</span> inside a
      Norwegian document; the formation of tags and
      subtags as defined in this document.  In particular it MUST
      specify Norwegian-speaking user could then access
      a French-Norwegian dictionary to find out what the marked section
      meant.  If the user were listening to that case is not significant.

   o  The specification MUST specify document through a canonical representation.
   o  The specification of valid subtags MUST
      speech synthesis interface, this formation could be available over used to signal
      the
      Internet and at no cost.
   o  The specification MUST synthesizer to appropriately apply French text-to-speech
      pronunciation rules to that span of text, instead of applying the
      inappropriate Norwegian rules.

4.3  Canonicalization of Language Tags

   Since a particular language tag may be used in the public domain many processes,
   language tags SHOULD always be created or available via a
      royalty-free license acceptable to the IETF and specified generated in the
      RFC.
   o a canonical
   form.

   A language tag is in canonical form when:

   1.  The specification MUST be versioned tag is well-formed according the rules in Section 2.1 and each version
       Section 2.2.

   2.  None of the
      specification MUST be numbered, dated, and stable.
   o  The specification MUST be stable.  That is, extension subtags,
      once defined by a specification, MUST NOT be retracted or change subtags in meaning the language tag has a canonical_value
       mapping in any substantial way.
   o the IANA registry (see Section 3.1).  Subtags with a
       canonical_value mapping MUST be informed of changes replaced with their mapping in
       order to canonicalize the contact information and
      URL for tag.

   3.  If more than one extension subtag sequence exists, the specification. extension
       sequences are ordered into case-insensitive ASCII order by
       singleton subtag.

   Example: The determination of whether an Internet-Draft meets the above
   conditions and the decision to grant or withhold such authority rests
   solely with language tag "en-A-aaa-B-ccc-bbb-x-xyz" is in canonical
   form, while "en-B-ccc-bbb-A-aaa-X-xyz" is well-formed but not in
   canonical form.

   Example: The language tag "en-NH" (English as used in the IESG, and New
   Hebrides) is subject not canonical because the 'NH' subtag has a canonical
   mapping to 'VU' (Vanuatu).

   Note: Canonicalization of language tags does not imply anything about
   the normal review and appeals
   process associated with use of upper or lowercase letter in subtags as described in
   Section 2.1.  All comparisons MUST be performed in a case-insensitive
   manner.

   Note: if the RFC process.

   Extension authors are strongly cautioned field 'Deprecated' appears in a registry record without
   an accompanying 'Canonical' field, then that many (including most
   well-formed) processors will be unaware of any special relationships tag or meaning inherent in subtag is
   deprecated without a replacement.  Validating processors SHOULD NOT
   generate tags that include these values, although the order of values are
   canonical when they appear in a language tag.

   An extension subtags.  Extension
   authors SHOULD avoid subtag MUST define any relationships or canonicalization
   mechanisms that interfere with matching or with length restrictions that may exist between the
   various subtags in common protocols where the extension is used.  In
   particular, applications may truncate and thus MAY define an alternate
   canonicalization scheme for the extension's subtags.  Extensions MAY
   define how the order of the extension's subtags are interpreted.  For
   example, an extension could define that its subtags are in doing matching
   or in fitting canonical
   order when the subtags are placed into limited lengths, so it is RECOMMENDED ASCII order: that is, "en-a-
   aaa-bbb-ccc" instead of "en-a-ccc-bbb-aaa".  Another extension might
   define that the
   most significant information be in order of the most significant (left-most)
   subtags, and subtags influences their semantic
   meaning (so that the specification gracefully handle truncated
   subtags.

   When "en-b-ccc-bbb-aaa" has a language tag is to different value from "en-b-
   aaa-bbb-ccc").  However, extension specifications SHOULD be used in a specific, known, protocol, it
   is RECOMMENDED that designed
   so that they are tolerant of the typical processes described in
   Section 3.6.

4.4  Considerations for Private Use Subtags

   Private-use subtags require private agreement between the parties
   that intend to use or exchange language tag not contain extensions not
   supported by tags that protocol.  In addition, it use them and great
   caution should be noted that
   some used in employing them in content or protocols may impose upper limits on the length
   intended for general use.  Private-use subtags are simply useless for
   information exchange without prior arrangement.

   The value and semantic meaning of private-use tags and of the strings subtags
   used to store or transport the language tag.

4.  Security Considerations

   The only security issue that has been raised with within such a language tags since
   the publication of RFC 1766, which stated that "Security issues tag are
   believed to be irrelevant to not defined by this memo", is a concern with language
   identifiers used document.

   The use of subtags defined in content negotiation - the IANA registry as having a specific
   private use meaning convey more information that they a purely private use
   tag prefixed by the singleton subtag 'x'.  For applications this
   additional information may be used to
   infer useful.

   For example, the nationality of region subtags 'AA', 'ZZ' and in the sender, ranges
   'QM'-'QZ' and thus identify potential
   targets for surveillance.

   This is 'XA'-'XZ' (derived from ISO 3166 private use codes) may
   be used to form a special case language tag.  A tag such as "zh-Hans-XQ" conveys a
   great deal of public, interchangeable information about the general problem that anything you send language
   material (that it is visible to Chinese in the receiving party.  It simplified Chinese script and is useful to be aware that
   such concerns can exist in
   suitable for some cases.

   The evaluation geographic region 'XQ').  While the precise
   geographic region is not known outside of private agreement, the exact magnitude tag
   conveys far more information than an opaque tag such as "x-someLang",
   which contains no information about the language subtag or script
   subtag outside of the threat, private agreement.

   However, in some cases content tagged with private use subtags may
   interact with other systems in a different and any possible
   countermeasures, is left possibly unsuitable
   manner compared to each application protocol.

   Although tags that use opaque, privately defined subtags,
   so the specification choice of valid subtags for an extension MUST be
   available over the Internet, implementations SHOULD NOT mechanically best approach may depend on it being always accessible, to prevent denial-of-service
   attacks. the particular
   domain in question.

5.  Character Set  IANA Considerations

   The syntax in

   This section deals with the processes and requirements necessary for
   IANA to undertake to maintain the rsubtag and extension registries as
   defined by this document requires that language tags use only the
   characters A-Z, a-z, 0-9, and HYPHEN-MINUS, which are present in most
   character sets, so presentation of language tags should not have any
   character set issues.

   Rendering accordance with the requirements of characters based
   RFC 2434 [11].

   The impact on the content IANA maintainers of the two registries defined by
   this document will be a language tag is not
   addressed small increase in this memo.  Historically, some languages have relied on the use frequency of specific character sets new
   entries or other information updates.

   Upon adoption of this document, the process described in order to
   infer how a specific character should Section 3.7
   will be rendered (notably this
   applies to language and culture specific variations of Han ideographs
   as used in Japanese, Chinese, and Korean).  When language tags are
   applied to spans of text, rendering engines may use that information
   in deciding which font to use in generate the absence initial Language Subtag Registry.  The
   initial set of other information,
   particularly where languages with distinct writing traditions use records represents no impact on IANA, since the
   same characters.

6.  Changes from RFC 3066 work
   to create it will be performed externally (as defined in that
   section).  The new registry will be listed under "Language Tags" at
   <http://www.iana.org/numbers.html>.  The main goals for this revision existing directory of language tags were the following:

   *Compatibility.* All valid
   registration forms and RFC 3066 language tags  (including those
   in the IANA registry)  remain valid in this specification.  Thus
   there is complete backward compatibility of this specification with
   existing content.  In addition, this document defines language tags
   in such as way registrations will be relabeled as to ensure future compatibility,
   "Language Tags (Obsolete)" and processors
   based solely maintained (but not added to or
   modified).

   Future work on the RFC 3066 ABNF (such as those described in XML
   Schema version 1.0) Language Subtag Registry will be able limited to process tags described
   inserting or replacing whole records preformatted for IANA by the
   Language Subtag Reviewer as described in Section 3.2 of this
   document.

   *Stability.* Because of  Each record will be sent to iana@iana.org with a subject
   line indicating whether the changes in underlying ISO standards, enclosed record is an insertion (of a
   valid RFC 3066 language tag may become invalid (or have its meaning
   change) at new
   record) or a later date.  With so much replacment of the world's computing
   infrastructure dependent on language tags, this is simply
   unacceptable: it invalidates content that may have an extensive
   shelf-life.  In this specification, once existing record which has a language tag is valid, it
   remains valid forever.  Previously, there was no way Type and
   Subtag (or Tag) field that exactly matches the record sent.  Records
   cannot be deleted from the registry.

   The Language Tag Extensions registry will also be generated and sent
   to determine
   when two tags were equivalent. IANA as described in Section 3.6.  This specification provides a stable
   mechanism for doing so, through the use of canonical forms.  These registry may contain at
   most 25 records and thus changes to this registry are also stable, so that implementations can depend expected to be
   very infrequent.

   Future work by IANA on the use of
   canonical forms Language Tag Extensions Registry is
   limited to assess equivalency.

   *Validity.*  The structure of language tags defined by two cases.  First, the IESG may request that new records
   be inserted into this document
   makes it possible registry from time to determine if a particular tag is well-formed
   without regard time.  These requests
   will include the record to insert in the exact format described in
   Section 3.6.  In addition, there may be occasional requests from the
   maintaining authority for a specific extension to update the actual content contact
   information or "meaning" of URLs in the tag as a
   whole.  This record.  These requests MUST include the
   complete, updated record.  IANA is important because not responsible for validating the registry and underlying
   standards  change over time.  In addition,
   information provided, only that it must is properly formatted.  It should
   reasonably be possible seen to
   determine if a tag is valid (or not) for a given point come from the maintaining authority named in time
   the record present in
   order the registry.

6.  Security Considerations

   The only security issue that has been raised with language tags since
   the publication of RFC 1766 [21], which stated that "Security issues
   are believed to provide reproducible, testable results.  This process must
   not be error-prone; otherwise even intelligent people will generate
   implementations irrelevant to this memo", is a concern with
   language identifiers used in content negotiation - that give different results.  This specification
   provides they may be
   used to infer the nationality of the sender, and thus identify
   potential targets for that by having surveillance.

   This is a single data file, with specific
   versioning information, so special case of the general problem that anything sent is
   visible to the validity of language tags at any
   point in time can be precisely determined (instead of interpolating
   values from many separate sources).

   *Extensibility.* receiving party and possibly to third parties as well.
   It is important useful to be able aware that such concerns can exist in some cases.

   The evaluation of the exact magnitude of the threat, and any possible
   countermeasures, is left to differentiate between
   written forms each application protocol (see BCP 72,
   RFC  3552 [15] for best current practice guidance on security threats
   and defenses).

   Although the specification of language -- valid subtags for many an extension MUST be
   available over the Internet, implementations SHOULD NOT mechanically
   depend on it being always accessible, to prevent denial-of-service
   attacks.

7.  Character Set Considerations

   The syntax in this is more
   important than distinguishing between spoken variants of a language.
   Languages document requires that language tags use only the
   characters A-Z, a-z, 0-9, and HYPHEN-MINUS, which are written present in a wide variety of different scripts, most
   character sets, so this
   document provides for the generative use composition of ISO 15924 script codes.
   Like language tags should not have
   any character set issues.

   Rendering of characters based on the generative use content of ISO a language and country codes tag is not
   addressed in RFC
   3066, this allows combinations memo.  Historically, some languages have relied on
   the use of specific character sets or other information in order to
   infer how a specific character should be produced without resorting rendered (notably this
   applies to
   the registration process.  The addition of UN codes provides for the
   generation of language tags with regional scope, which is also
   required for information technology.

   The recast and culture specific variations of the registry from containing whole Han ideographs
   as used in Japanese, Chinese, and Korean).  When language tags are
   applied to
   subtags is a key part of this.  An important feature spans of RFC 3066 was
   that it allowed generative text, rendering engines may use of subtags.  This allows people that information
   in deciding which font to
   meaningfully use generated tags, without the delays in registering
   whole tags, and the burden on the registry of having to supply all of
   the combinations that people may find useful.

   Because absence of the widespread other information,
   particularly where languages with distinct writing traditions use of language tags, it is potentially
   disruptive to have periodic revisions of the core specification,
   despite demonstrated need.
   same characters.

8.  Changes from RFC 3066

   The extension mechanism provides for a
   way main goals for independent RFCs to define extensions to language tags.
   These extensions have a very constrained, well-defined structure to
   prevent extensions from interfering with implementations this revision of language tags defined were the following:

   *Compatibility.* All valid RFC 3066 language tags  (including those
   in the IANA registry)  remain valid in this document.  The document also anticipates
   features specification.  Thus
   there is complete backward compatibility of ISO 639-3 this specification with the addition of the extlang subtags.  The
   use and definition of private use
   existing content.  In addition, this document defines language tags has also been modified, to
   allow people to move
   in such as much information way as possible out of private
   use tags, and into the regular structure.  The goal is to
   dramatically reduce ensure future compatibility, and processors
   based solely on the need RFC 3066 ABNF (such as those described in XML
   Schema version 1.0 [19]) will be able to produce a revision of process tags described by
   this document
   in document.

   *Stability.* Because of the future.

   The specific changes in underlying ISO standards, a
   valid RFC 3066 language tag may become invalid (or have its meaning
   change) at a later date.  With so much of the world's computing
   infrastructure dependent on language tags, this document is simply
   unacceptable: it invalidates content that may have an extensive
   shelf-life.  In this specification, once a language tag is valid, it
   remains valid forever.  Previously, there was no way to meet these goals are:
   o  Defines the ABNF and rules determine
   when two tags were equivalent.  This specification provides a stable
   mechanism for subtags doing so, through the use of canonical forms.  These
   are also stable, so that implementations can depend on the category use of all
      subtags can be determined without reference
   canonical forms to the registry.
   o  Adds the concept assess equivalency.

   *Validity.*  The structure of well-formed vs.  validating processors,
      defining the rules language tags defined by which an implementation can claim this document
   makes it possible to be one
      or determine if a particular tag is well-formed
   without regard for the other.
   o  Changes actual content or "meaning" of the IANA language tag registry to as a language subtag
   whole.  This is important because the registry that provides and underlying
   standards  change over time.  In addition, it must be possible to
   determine if a complete list of tag is valid subtags (or not) for a given point in the
      IANA registry. time in
   order  to provide reproducible, testable results.  This allows for robust implementation and ease of
      maintenance.  The language subtag registry becomes the canonical
      source process must
   not be error-prone; otherwise even intelligent people will generate
   implementations that give different results.  This specification
   provides for forming language tags.
   o  Provides that by having a process single data file, with specific
   versioning information, so that guarantees stability the validity of language tags, by
      handling reuse tags at any
   point in time can be precisely determined (instead of interpolating
   values by ISO 639, ISO 15924, and ISO 3166 from many separate sources).

   *Extensibility.* It is important to be able to differentiate between
   written forms of language -- for many implementations this is more
   important than distinguishing between spoken variants of a language.
   Languages are written in
      the event that they register a previously used value wide variety of different scripts, so this
   document provides for a new
      purpose.
   o  Allows the generative use of ISO 15924 script code subtags and allows them to be used
      generatively.  Adds codes.
   Like the concept generative use of a variant subtag ISO language and country codes in RFC
   3066, this allows
      variants combinations to be used generatively.  Adds the ability produced without resorting to use a class
      of UN tags as regions.
   o  Defines the private-use tags in ISO 639, ISO 15924, and ISO 3166
      as
   the mechanism for creating private-use language, script, and
      region subtags respectively.
   o  Adds a well-defined extension mechanism.
   o  Defines an extended language subtag, possibly for use with certain
      anticipated features of ISO 639-3.

   Ed Note: registration process.  The following items are provided addition of UN codes provides for the convenience
   generation of language tags with regional scope, which is also
   required for information technology.

   The recast of
   reviewers and will be removed from the final document.

   Changes between draft-phillips-langtags-10 and this version are:
   o  Expunged the terminology "language range", since that section goes
      with matching (A.Phillips, M.Davis)
   o  Added text describing the handling registry from containing whole language tags to
   subtags is a key part of this.  An important feature of existing RFC 3066 registry
      entries was
   that were deprecated prior it allowed generative use of subtags.  This allows people to
   meaningfully use generated tags, without the adoption of this
      document.  These tags are now grandfathered.  (A.Phillips,
      D.Ewell)
   o  Modified delays in registering
   whole tags, and the conversion rules for burden on the registry (Appendix C) to
      refer of having to supply all of
   the chairs, the LTRU mail list and so forth (A.Phillips)
   o  Added text to allow tags and subtags to be deprecated using combinations that people may find useful.

   Because of the
      canonical value "--".  This widespread use of language tags, it is applied potentially
   disruptive to codes withdrawn by ISO
      639 MA and ISO 3166 MA, for example.  (F.Ellerman, D.Ewell)

7.  References

   [1]   International Organization for Standardization, "ISO
         639-1:2002, Codes for the representation of names have periodic revisions of languages
         -- Part 1: Alpha-2 code", ISO Standard 639, 2002.

   [2]   International Organization the core specification,
   despite demonstrated need.  The extension mechanism provides for Standardization, "ISO 639-2:1998
         - Codes a
   way for the representation independent RFCs to define extensions to language tags.
   These extensions have a very constrained, well-defined structure to
   prevent extensions from interfering with implementations of names language
   tags defined in this document.  The document also anticipates
   features of languages -- Part 2:
         Alpha-3 code - edition 1", August 1988.

   [3] ISO TC46/WG3, "ISO 15924:2003 (E/F) - Codes for 639-3 with the
         representation of names addition of scripts", January 2004.

   [4]   International Organization for Standardization, "Codes for the
         representation of names extended language
   subtags, as well as the possibility of countries, 3rd edition",
         ISO Standard 3166, August 1988.

   [5]   Statistical Division, United Nations, "Standard Country or Area
         Codes for Statistical Use", UN Standard Country or Area Codes
         for Statistical Use, Revision 4 (United Nations publication,
         Sales No. 98.XVII.9, June 1999.

   [6]   ISO 639 Joint Advisory Committee, "ISO 639 Joint Advisory
         Committee:  Working principles for other ISO 639 maintenance", March
         2000,
         <http://www.loc.gov/standards/iso639-2/iso639jac_n3r.html>.

   [7]   Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
         and RFC 822", RFC 1327, May 1992.

   [8]   Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
         Extensions) Part One: Mechanisms parts becoming
   useful for Specifying and Describing the Format formation of Internet Message Bodies", RFC 1521, September
         1993.

   [9]   Alvestrand, H., "Tags for language tags in the Identification future.  The use and
   definition of Languages",
         RFC 1766, March 1995.

   [10]  Hovey, R. private use tags has also been modified, to allow
   people to move as much information as possible out of private use
   tags, and S. Bradner, "The Organizations Involved into the regular structure.  The goal is to dramatically
   reduce the need to produce a revision of this document in the
         IETF Standards Process", BCP 11, RFC 2028, October 1996.

   [11]  Bradner, S., "Key words for use future.

   The specific changes in RFCs this document to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [12]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
         Extensions: Character Sets, Languages, and Continuations",
         RFC 2231, November 1997.

   [13]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, November 1997.

   [14]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396, August
         1998.

   [15]  Narten, T. meet these goals are:

   o  Defines the ABNF and H. Alvestrand, "Guidelines rules for Writing subtags so that the category of all
      subtags can be determined without reference to the registry.

   o  Adds the concept of well-formed vs. validating processors,
      defining the rules by which an implementation can claim to be one
      or the other.

   o  Replaces the IANA
         Considerations Section language tag registry with a language subtag
      registry that provides a complete list of valid subtags in RFCs", BCP 26, RFC 2434, October
         1998.

   [16]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

   [17]  Carpenter, B., Baker, F. the
      IANA registry.  This allows for robust implementation and M. Roberts, "Memorandum ease of
         Understanding Concerning
      maintenance.  The language subtag registry becomes the Technical Work canonical
      source for forming language tags.

   o  Provides a process that guarantees stability of language tags, by
      handling reuse of values by ISO 639, ISO 15924, and ISO 3166 in
      the Internet
         Assigned Numbers Authority", RFC 2860, June 2000.

   [18]  Alvestrand, H., "Tags event that they register a previously used value for a new
      purpose.

   o  Allows ISO 15924 script code subtags and allows them to be used
      generatively.  Adds the Identification concept of Languages",
         BCP 47, RFC 3066, January 2001.

   [19]  Yergeau, F., "UTF-8, a transformation format variant subtag and allows
      variants to be used generatively.  Adds the ability to use a class
      of UN tags as regions.

   o  Defines the private-use tags in ISO 10646",
         STD 63, RFC 3629, November 2003.

   [20]  Klyne, G. 639, ISO 15924, and C. Newman, "Date ISO 3166
      as the mechanism for creating private-use language, script, and Time on
      region subtags respectively.

   o  Adds a well-defined extension mechanism.

   o  Defines an extended language subtag, possibly for use with certain
      anticipated features of ISO 639-3.

   Ed Note: The following items are provided for the Internet:
         Timestamps", RFC 3339, July 2002.

   [21]  <http://www.ietf.org/rfc/rfc2026.txt>

Authors' Addresses

   Addison Phillips (editor)
   Quest Software

   Email: addison.phillips@quest.com

   Mark Davis (editor)
   IBM

   Email: mark.davis@us.ibm.com

Appendix A.  Acknowledgements

   Any list convenience of contributors is bound to
   reviewers and will be incomplete; please regard the
   following as only a selection removed from the group of people who have
   contributed final document.

   Changes between draft-ietf-ltru-registry-00 and this version are:

   o  Updated the ABNF for singleton to make this document what it is today.

   The contributors conform to RFC 3066 2234 and RFC 1766,
      pass the precursors Fenner parser (F.Ellermann)

   o  Split the references into informative and normative lists.
      Eliminated dead references carried forward from previous versions
      of this
   document, made enormous contributions directly or indirectly document.  (A.Phillips)

   o  Added a reference to RFC 3552 (BCP 72) to this
   document and are generally responsible for the success Security
      Considerations section (I.McDonald)

   o  Modified the first sentence in Section 2.1.1 from "on the number
      of language
   tags.

   The following people (in alphabetical order) contributed to this
   document or size of subtags in a Language Tag" to RFCs 1766 be proper English and 3066:

   Glenn Adams, Harald Tveit Alvestrand, Tim Berners-Lee, Marc Blanchet,
   Nathaniel Borenstein, Eric Brunner, Sean M.  Burke, Jeremy Carroll,
   John Clews, Jim Conklin, Peter Constable, John Cowan, Mark Crispin,
   Dave Crocker, Martin Duerst, Frank Ellerman, Michael Everson, Doug
   Ewell, Ned Freed, Tim Goodwin, Dirk-Willem van Gulik, Marion Gunn,
   Joel Halpren, Elliotte Rusty Harold, Paul Hoffman, Richard Ishida,
   Olle Jarnefors, Kent Karlsson, John Klensin, Alain LaBonte, Eric
   Mader, Keith Moore, Chris Newman, Masataka Ohta, George Rhoten,
   Markus Scherer, Keld Jorn Simonsen, Thierry Sourbier, Otto Stolz, Tex
   Texin, Andrea Vine, Rhys Weatherley, Misha Wolf, Francois Yergeau
      convey more meaning.  (A.Phillips)

   o  Various examples that used the variant 'boont' were changes to use
      the variant 'scouse' instead.  (J.Cowan)

   o  Added an additional example ("en-a-bbb-x-a-ccc") to the extension/
      singleton rules in Section 2.2.6 to illustrate that singletons can
      recur in private use sequences (A.Phillips)

   o  Modified the sentence describing the possibilities for variant
      registration (see Section 3.5)  to include transliterations and
   many, many others.

   Very special thanks must go
      other transformations per discussion on the list.  (M.T. Carrasco
      Benitez)

   o  Converted the format of the registry to Harald Tveit Alvestrand, who
   originated RFCs 1766 record-jar format.  This
      subtantially replaces section 3.1 (R.Presuhn)

   o  Subtantially revised the rules for registry creation to reflect
      the Date A/B boundaries on adopting ISO 3166 codes (J.Cowan)

   o  Modified the registration process section and 3066, form to deal with
      both new additions and without whom revisions of records, as well as making
      life easier on the Subtag Reviewer by matching the fields to the
      registry format.  (A.Phillips)

   o  Changed the reference to RFC 2234 to RFC 2234bis (recently
      adopted).  (S.Hollenbeck)

   o  Modifications to make this document would
   not have been possible.  Special thanks must go conformant with RFC 3978
      (recently adopted).  (R.Presuhn)

   o  Added an informative reference to Michael Everson,
   who has served as language tag reviewer for almost XML Schema 1.0 Part 2: Second
      Edition in this section.  (J.Morfin)

   o  Expanded the complete
   period since jargon-ish 'extlang' to "extended language" in this
      section.  (J.Morfin)

   o  Corrected an egregious error in the publication ABNF (%x6A -> %x5A in one of RFC 1766.  Special thanks to Doug
   Ewell, for his production
      the ranges) (A.Phillips)

   o  Split Maintenance of the first complete subtag registry, and
   his work in producing a test parser for verifying language tags.

Appendix B.  Examples Registry from Format of Language Tags (Informative)

   Simple language subtag:
      de (German)
      fr (French)
      ja (Japanese)
      i-enochian (example the Registry
      (A.Phillips)

   o  Revision of a grandfathered tag)

   Language subtag plus Script subtag:
      zh-Hant (Traditional Chinese)
      en-Latn (English written in Latin script)
      sr-Cyrl (Serbian written section Section 3.4 to make it consistent with Cyrillic script)

   Language-Script-Region:
      zh-Hans-CN (Simplified Chinese for the PRC)
      sr-Latn-CS (Serbian, Latin script, Serbia new
      section Section 3.2.  (A.Phillips)

   o  Separated IANA Considerations section from the registry definition
      and Montenegro)

   Language-Script-Region-Variant:
      en-Latn-US-boont (Boontling dialect registration procedures. ()

   o  Added additional choice information dealing with scripts and
      extlangs.  These items were also moved to a new section following
      the registry format because of English)
      de-Latn-CH-1996 (German written in Latin script interdependence.

   o  Updated the IANA Considerations section.

   o  Added appeal and maintenance requirements to the extensions
      Section 3.6 section.  (A.Phillips)

   o  Added an additional bullet point to Section 3.5 enumerating the
      changes that can be registered to a record (previously we only
      listed the options for Switzerland
      using new subtags).  (A.Phillips)

   o  Added the orthography phrase ", as well as the possibility of 1996)

   Language-Region:
      de-DE (German for Germany)
      zh-SG (Chinese for Singapore)
      cs-200 (Czech for Czechoslovakia)
      sr-CS (Serbian for Serbia and Montenegro)
      es-419 (Spanish other ISO 639
      parts becoming useful for Latin America and Caribbean region using the
      UN region code)

   Other Mixtures:
      en-boont (Boontling dialect formation of English)

   private-use mechanism:
      de-CH-x-phonebk
      az-Arab-x-AZE-derbend

   Extended language subtags (examples ONLY: extended languages must be
   defined by revision or update to this document):
      zh-min
      zh-min-nan-Hant-CN

   Private-use subtags:
      x-whatever (private use using tags in the singleton 'x')
      qaa-Qaaa-QM-x-southern (all private tags)
      de-Qaaa (German, with a private script)
      de-Latn-QM (German, Latin-script, private region)
      de-Qaaa-DE (German, private script, for Germany)

   Tags that use extensions (examples ONLY: extensions must be defined
   by revision or update
      future" to this document or by RFC):
      en-US-u-islamCal
      zh-CN-a-myExt-x-private
      en-a-myExt-b-another

   Some Invalid Tags:
      de-419-DE (two region tags)
      a-DE (use of a single character subtag section in primary position; note
      that there are a few grandfathered tags that start with "i-" that
      are valid)
      ar-a-aaa-b-bbb-a-ccc (two extensions with same single letter
      prefix)

Appendix C.  Conversion anticipation of revising the ABNF to
      allow for the RFC 3066 Language Tag Registry

   Upon publication possibility of ISO 639-6 being used in language tags
      in a future revision of this document document.  (D.Garside)

   o  Added the concept of 'Suppress-Script' to Section 4.1, as a BCP, well as
      to the existing IANA
   language tag registry must be converted into format in Section 3.1, Section 3.3 and
      Section 3.2. (many)

   o  Added text requiring the new subtag registry.
   This section I-D that defines an extension to choose a
      letter (and allowing the process IESG to change it if necessary).
      (D.Ewell?)

   o  Removed the ABNF notes from the text about case insensitivity
      (F.Ellermann)

   o  Removed the second, rather repetitive reference to Appendix B in
      Section 2.1 (A.Phillips)

   o  Fixed missing whitesapce in Section 2.1 (F.Ellermann)

   o  Changed "empty" to "omitted" in Section 2.2.1 (F.Ellermann)

   o  Changed the intro to Section 2.2.1 and otherwise tugged at that
      section to deal with i-* grandfathered items.  (F.Ellermann)

   o  Reserved alpha4 language subtags for performing future standardization.
      (D.Garside)

   o  Incorporate changes to be consistent with RFC 3978, including the
      new xml2rfc processor.  Note that this conversion.

   The impact has an effect on the IANA maintainers ABNF,
      since some of the registry comments were too wide previously (comments were
      revised to fit the 72 character maximum).  (S.Hollenbeck)

   o  Remove the Latin-1 restriction on the 'Description' field.
      Provide guidance for registration of this conversion
   will be content, including a small increase
      requirement for at least one representation in the Latin script.
      (F.Ellermann, A.Phillips)

   o  Make the variant subtlety less so.  (F.Ellermann)

   o  Various 'you' removals and cleanup (M.Davis)

   o  Inserted additional non-normative caveat about the 'MUL' subtag
      (A.Phillips)

   o  Various editorial edits (J.Cowan)

   o  Use normative language when giving permission to not store long
      language tags in Section 2.1.1.  (J.Cowan)

9.  References

9.1  Normative References

   [1]   International Organization for Standardization, "ISO 639-
         1:2002, Codes for the representation of names of languages --
         Part 1: Alpha-2 code", ISO Standard 639, 2002.

   [2]   International Organization for Standardization, "ISO 639-2:1998
         - Codes for the representation of names of languages -- Part 2:
         Alpha-3 code - edition 1", August 1988.

   [3]   ISO TC46/WG3, "ISO 15924:2003 (E/F) - Codes for the frequency
         representation of new entries.  The
   initial set names of records represents no impact on IANA, since scripts", January 2004.

   [4]   International Organization for Standardization, "Codes for the work
         representation of names of countries, 3rd edition",
         ISO Standard 3166, August 1988.

   [5]   Statistical Division, United Nations, "Standard Country or Area
         Codes for Statistical Use", UN Standard Country or Area Codes
         for Statistical Use, Revision 4 (United Nations publication,
         Sales No. 98.XVII.9, June 1999.

   [6]   International Organization for Standardization, "ISO/IEC 10646-
         1:2000. Information technology -- Universal Multiple-Octet
         Coded Character Set (UCS) -- Part 1: Architecture and Basic
         Multilingual Plane and ISO/IEC 10646-2:2001. Information
         technology -- Universal Multiple-Octet Coded Character Set
         (UCS) -- Part 2: Supplementary Planes, as, from time to create it will be performed externally.

   When this document is published, an email will be sent time,
         amended, replaced by a new edition or expanded by the
   chair(s) addition
         of new parts", 2000.

   [7]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", draft-crocker-abnf-rfc2234bis-00 (work
         in progress), March 2005.

   [8]   Bradner, S., "The Internet Standards Process -- Revision 3",
         BCP 9, RFC 2026, October 1996.

   [9]   Hovey, R. and S. Bradner, "The Organizations Involved in the LTRU working group
         IETF Standards Process", BCP 11, RFC 2028, October 1996.

   [10]  Bradner, S., "Key words for use in RFCs to the LTRU Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [11]  Narten, T. and ietf-languages
   mail lists advising of the impending conversion of the registry.  In
   that notice, the chair(s) will provide a URL whose referred content
   is the proposed H. Alvestrand, "Guidelines for Writing an IANA Language Subtag Registry following conversion.
   There will be a Last Call period
         Considerations Section in RFCs", BCP 26, RFC 2434,
         October 1998.

   [12]  Hoffman, P. and F. Yergeau, "UTF-16, an encoding of not less than four weeks for
   comments ISO 10646",
         RFC 2781, February 2000.

   [13]  Carpenter, B., Baker, F., and corrections to be discussed on the
   ietf-languages@iana.org mail list.  Changes as a result M. Roberts, "Memorandum of comments
   will not restart the Last Call period.  At
         Understanding Concerning the end Technical Work of the period, the
   chair(s) will forward the URL to IANA, which will post Internet
         Assigned Numbers Authority", RFC 2860, June 2000.

   [14]  Klyne, G. and C. Newman, "Date and Time on the new
   registry on-line.

   Tags that are currently deprecated will be maintained as
   grandfathered entries. Internet:
         Timestamps", RFC 3339, July 2002.

   [15]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
         Security Considerations", BCP 72, RFC 3552, July 2003.

9.2  Informative References

   [16]  ISO 639 Joint Advisory Committee, "ISO 639 Joint Advisory
         Committee:  Working principles for ISO 639 maintenance",
         March 2000,
         <http://www.loc.gov/standards/iso639-2/iso639jac_n3r.html>.

   [17]  Raymond, E., "The Art of Unix Programming", 2003.

   [18]  Bray (et al), T., "Extensible Markup Language (XML) 1.0",
         02 2004.

   [19]  Biron, P., Ed. and A. Malhotra, Ed., "XML Schema Part 2:
         Datatypes Second Edition", 10 2004, <
         http://www.w3.org/TR/xmlschema-2/>.

   [20]  Unicode Consortium, "The Unicode Consortium. The record Unicode
         Standard, Version 4.1.0, defined by: The Unicode Standard,
         Version 4.0 (Boston, MA, Addison-Wesley, 2003. ISBN 0-321-
         18578-1), as amended by Unicode 4.0.1
         (http://www.unicode.org/versions/Unicode4.0.1) and by Unicode
         4.1.0 (http://www.unicode.org/versions/Unicode4.1.0).",
         March 2005.

   [21]  Alvestrand, H., "Tags for the grandfathered entry will
   contain a note indicating that the entry is 'deprecated' Identification of Languages",
         RFC 1766, March 1995.

   [22]  Freed, N. and reason K. Moore, "MIME Parameter Value and Encoded Word
         Extensions: Character Sets, Languages, and Continuations",
         RFC 2231, November 1997.

   [23]  Alvestrand, H., "Tags for the deprecation.  For example, the tag "art-lojban" Identification of Languages",
         BCP 47, RFC 3066, January 2001.

Authors' Addresses

   Addison Phillips (editor)
   Quest Software

   Email: addison.phillips@quest.com

   Mark Davis (editor)
   IBM

   Email: mark.davis@us.ibm.com

Appendix A.  Acknowledgements

   Any list of contributors is deprecated
   and will bound to be placed in incomplete; please regard the grandfathered section.

   Tags that are not deprecated that consist entirely
   following as only a selection from the group of subtags that
   are valid under this document and which people who have the correct form and
   format for tags defined by
   contributed to make this document are superseded by this
   document.  Such tags are placed in the 'redundant' section of the
   registry.  For example, zh-Hant what it is now defined by this document.

   Tags that contain subtags which are consistent with registration
   under today.

   The contributors to RFC 3066 and RFC 1766, the guidelines in this document will have a new subtag
   registration created for each eligible subtag.  If all precursors of the subtags
   in the original tag are fully defined by the resulting registrations
   or by this
   document, then the original tag is superseded by made enormous contributions directly or indirectly to this
   document.  Such tags
   document and are placed in generally responsible for the 'redundant' section success of the
   registry.  For example, en-boont will result in a new subtag "boont" language
   tags.

   The following people (in alphabetical order) contributed to this
   document or to RFCs 1766 and 3066:

   Glenn Adams, Harald Tveit Alvestrand, Tim Berners-Lee, Marc Blanchet,
   Nathaniel Borenstein, Eric Brunner, Sean M. Burke, M.T. Carrasco
   Benitez, Jeremy Carroll, John Clews, Jim Conklin, Peter Constable,
   John Cowan, Mark Crispin, Dave Crocker, Martin Duerst, Frank
   Ellerman, Michael Everson, Doug Ewell, Ned Freed, Tim Goodwin, Dirk-
   Willem van Gulik, Marion Gunn, Joel Halpren, Elliotte Rusty Harold,
   Paul Hoffman, Scott Hollenbeck, Richard Ishida, Olle Jarnefors, Kent
   Karlsson, John Klensin, Alain LaBonte, Eric Mader, Ira McDonald,
   Keith Moore, Chris Newman, Masataka Ohta, Randy Presuhn, George
   Rhoten, Markus Scherer, Keld Jorn Simonsen, Thierry Sourbier, Otto
   Stolz, Tex Texin, Andrea Vine, Rhys Weatherley, Misha Wolf, Francois
   Yergeau and the RFC 3066 registered tag 'en-boont' placed in the redundant
   section of the registry.

   Tags that contain one or more subtags that do not match the valid
   registration pattern many, many others.

   Very special thanks must go to Harald Tveit Alvestrand, who
   originated RFCs 1766 and which are not otherwise defined by 3066, and without whom this document are marked would
   not have been possible.  Special thanks must go to Michael Everson,
   who has served as 'grandfathered' by this document.

   There will be a reasonable period in which the community may comment
   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
   notify iana@iana.org and the ltru and ietf-languages mail lists that language tag reviewer for almost the task is complete and forward
   period since the necessary materials publication of RFC 1766.  Special thanks to IANA Doug
   Ewell, for
   publication.

   Registrations that are in process under the rules defined in RFC 3066
   MAY be completed under the former rules, at the discretion his production of the
   language tag reviewer.  Any new registrations submitted after the
   request first complete subtag registry, and
   his work in producing a test parser for conversion verifying language tags.

Appendix B.  Examples of the registry MUST be rejected.

   All existing RFC 3066 Language Tags (Informative)

   Simple language tag registrations will be maintained
   in perpetuity.

   Users subtag:

      de (German)

      fr (French)

      ja (Japanese)

      i-enochian (example of tags that are grandfathered should consider registering
   appropriate subtags in the IANA a grandfathered tag)

   Language subtag registry (but are not required
   to).

   Where two subtags have plus Script subtag:

      zh-Hant (Chinese written using the same meaning, Traditional Chinese script)

      zh-Hans (Chinese written using the priority of which to
   make canonical SHALL be Simplified Chinese script)

      sr-Cyrl (Serbian written using the following:
   o  As of  Cyrillic script)

      sr-Latn (Serbian written using the date of acceptance of this document Latin script)

   Language-Script-Region:

      zh-Hans-CN (Chinese written using the Simlified script as a BCP, if a code
      exists used in
      mainland China)

      sr-Latn-CS (Serbian written using the associated ISO standard Latin script as used in
      Serbia and it is not deprecated or
      withdrawn Montenegro)

   Language-Variant:

      en-boont (Boontling dialect of English)

      en-scouse (Scouse dialect of English)

   Language-Region-Variant:

      en-GB-scouse (Scouse dialect of English as used in the UK)

   Language-Script-Region-Variant:

      sl-Latn-IT-nedis (Nadiza dialect of that date, then it has priority.
   o  Otherwise, Slovenian written using the earlier-registered
      Latin script as used in Italy.  Note that this tag is not
      recommended because subtag 'sl' has a Suppress-Script value of
      'Latn')

   Language-Region:

      de-DE (German for Germany)

      en-US (English as used in the associated ISO
      standard has priority. United States)

      es-419 (Spanish for Latin America and Caribbean region using the
      UN numeric codes assigned to 'macro-geographical (continental)' region code)

   Private-use subtags:

      de-CH-x-phonebk

      az-Arab-x-AZE-derbend

   Extended language subtags (examples ONLY: extended languages must be
   defined by revision or
   sub-regions not associated update to this document):

      zh-min

      zh-min-nan-Hant-CN

   Private-use registry values:

      x-whatever (private use using the singleton 'x')

      qaa-Qaaa-QM-x-southern (all private tags)

      de-Qaaa (German, with an assigned ISO 3166 alpha-2 code are a private script)

      sr-Latn-QM (Serbian, Latin-script, private region)

      sr-Qaaa-CS (Serbian, private script, for Serbia and Montenegro)

   Tags that use extensions (examples ONLY: extensions must be defined
   by revision or update to this document or by RFC):

      en-US-u-islamCal

      zh-CN-a-myExt-x-private

      en-a-myExt-b-another

   Some Invalid Tags:

      de-419-DE (two region tags)
      a-DE (use of a single character subtag in the IANA registry and primary position; note
      that there are valid for use a few grandfathered tags that start with "i-" that
      are valid)

      ar-a-aaa-b-bbb-a-ccc (two extensions with same single letter
      prefix)

Appendix C.  Example Registry

   Example Registry

   File-Date: 2005-04-18
   %%
   Type: language
   Subtag: aa
   Description: Afar
   Added: 2004-07-06
   %%
   Type: language
   Subtag: ab
   Description: Abkhazian
   Added: 2004-07-06
   %%
   Type: language
   Subtag: ae
   Description: Avestan
   Added: 2004-07-06
   %%
   Type: language
   Subtag: ar
   Description: Arabic
   Added: 2004-07-06
   Suppress-Script: Arab
   Comment: Arabic text is usually written in Arabic script
   %%
   Type: language tags.
   These
   Subtag: qaa..qtz
   Description: PRIVATE USE
   Added: 2004-08-01
   Comment: Use private use codes MUST be added in preference
     to the initial version x- singleton for primary language
   Comment: This is an example of the registry. two comments.
   %%
   Type: script
   Subtag: Arab
   Description: Arabic
   Added: 2004-07-06
   %%
   Type: script
   Subtag: Armn
   Description: Armenian
   Added: 2004-07-06
   %%
   Type: script
   Subtag: Bali
   Description: Balinese
   Added: 2004-07-06
   %%
   Type: script
   Subtag: Batk
   Description: Batak
   Added: 2004-07-06
   %%
   Type: region
   Subtag: AA
   Description: PRIVATE USE
   Added: 2004-08-01
   %%
   Type: region
   Subtag: AD
   Description: Andorra
   Added: 2004-07-06
   %%
   Type: region
   Subtag: AE
   Description: United Arab Emirates
   Added: 2004-07-06
   %%
   Type: region
   Subtag: AX
   Description: &#xC5;land Islands
   Added: 2004-07-06
   Comments: The UN numeric codes description shows a Unicode escape
     for 'economic groupings' or 'other groupings',
   and the alphanumeric codes letter A-ring.
   %%
   Type: region
   Subtag: 001
   Description: World
   Added: 2004-07-06
   %%
   Type: region
   Subtag: 002
   Description: Africa
   Added: 2004-07-06
   %%
   Type: region
   Subtag: 003
   Description: North America
   Added: 2004-07-06
   %%
   Type: variant
   Subtag: 1901
   Description: Traditional German
      orthography
   Added: 2004-09-09
   Recommended-Prefix: de
   Comment: <shows continuation>
   %%
   Type: variant
   Subtag: 1996
   Description: German orthography of 1996
   Added: 2004-09-09
   Recommended-Prefix: de
   %%
   Type: variant
   Subtag: boont
   Description: Boontling
   Added: 2003-02-14
   Recommended-Prefix: en
   %%
   Type: variant
   Subtag: gaulish
   Description: Gaulish
   Added: 2001-05-25
   Recommended-Prefix: cel
   %%
   Type: grandfathered
   Tag: art-lojban
   Description: Lojban
   Added: 2001-11-11
   Canonical: jbo
   Deprecated: 2003-09-02
   %%
   Type: grandfathered
   Tag: en-GB-oed
   Description: English, Oxford English Dictionary spelling
   Added: 2003-07-09
   %%
   Type: grandfathered
   Tag: i-ami
   Description: 'Amis
   Added: 1999-05-25
   %%
   Type: grandfathered
   Tag: i-bnn
   Description: Bunun
   Added: 1999-05-25
   %%
   Type: redundant
   Tag: az-Arab
   Description: Azerbaijani in Appendix X Arabic script
   Added: 2003-05-30
   %%
   Type: redundant
   Tag: az-Cyrl
   Description: Azerbaijani in Cyrillic script
   Added: 2003-05-30
   %%

                 Figure 7: Example of the UN document MUST NOT
   be added to the registry. Registry Format

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.