Subject: [Ltru] Pre-draft-00 for RFC 4645bis

From: "Doug Ewell" <[email-masked]>
Date: Wed, 27 Sep 2006 23:44:25 -0700

I've finished the text for draft-4645bis-00, but haven't yet moved it 
into xml2rfc or added references.

Below is the text I propose for the Abstract and the first five 
sections, excluding the Registry data itself, the References section, 
and the required boilerplate.  Please read it and make any comments.  I 
hope to submit a version generated by xml2rfc in the next day or two.

As before, the prototype Registry built using these rules is available 
at:

http://users.adelphia.net/~dewell/lstreg-4646bis.txt
http://users.adelphia.net/~dewell/lstreg-4646bis.zip

-----8<-----cut here-----8<-----cut here-----8<-----cut here-----8<-----

RFC 4645bis
Update to the Language Subtag Registry

Abstract

This memo defines the procedure used to update the IANA Language Subtag 
Registry in conjunction with the publication of [draft-4646bis], for use 
in forming tags for the identification of languages.  As an 
Internet-Draft, it also contained the complete updated contents of the 
Registry.  To prevent confusion, this material was removed before 
publication.

1.  Introduction

[RFC4646] provided for a Language Subtag Registry and described its 
format.  The initial contents of the Registry and rules for determining 
them were specified in [RFC4645].

[draft-4646bis] expands on [RFC4646] by adding support for almost 7,200 
primary and extended language subtags based on [ISO639-3] alpha-3 code 
elements.  This memo describes the process of updating the Registry to 
include these additional subtags, and to make secondary changes to the 
Registry that result from adding the new subtags.

In its initial phase as an Internet-Draft, this memo also contained the 
complete updated contents of the Language Subtag Registry.  The purpose 
was to deliver a complete, revised Registry to the Internet Assigned 
Numbers Authority (IANA), replacing the previous version.  This content 
was deleted from this memo prior to publication as an RFC.

The format of the Language Subtag Registry, and the definition and 
intended purpose of each of the fields, are described in 
[draft-4646bis].

The Registry is expected to change over time, as new subtags are 
registered and existing subtags are modified or deprecated.  The process 
of updating the Registry is described in Section 3 of [draft-4646bis]. 
In its Internet-Draft stage, this memo did not define the permanent 
contents of the Registry and should not be represented as doing so.

Many of the subtags defined in the Language Subtag Registry are based on 
code elements defined in [ISO639-1], [ISO639-2], [ISO639-3], 
[ISO3166-1], [ISO15924], and [UN_M.49].  The Registry is not a mirror of 
the code lists defined by the standards and should not be used as one.

2.  Updating the Registry

This section describes the process for determining the updated contents 
of the Language Subtag Registry.

2.1.  Starting point

The version of the Language Subtag Registry that was current at the time 
of IESG approval of this memo served as the starting point for this 
update.  The process of creating that version was described in 
[RFC4645].

The source data for [ISO639-3] used for this update consisted of two 
files, [iso-dis-639-3_20060421] and 
[iso-dis-639-3-macrolanguages_20060922], available from the official 
site of the ISO 639-3 Registration Authority.  [RFC EDITOR NOTE: this 
information is expected to be updated before approval of this memo.]

• [iso-dis-639-3_20060421] is a list of all language code elements in 
[ISO639-3], including the alpha-3 code element and inverted name for 
each code element.  For example, the entry for Northwestern Kolami 
contained the code element “kfb” and the name “Kolami, Northwestern” 
(among other things).

• [iso-dis-639-3-macrolanguages_20060922] is a list of all alpha-3 code 
elements for languages that are contained within a macrolanguage in 
[ISO639-3], together with the alpha-3 code element for the 
macrolanguage.  For example, a line containing the code elements “mon” 
and “khk” indicated that the macrolanguage “Mongolian” includes the 
individual language “Mongolian, Halh”.  (Note that these alpha-3 code 
elements may not have corresponded directly to subtags in the Registry, 
which uses 2-letter subtags derived from [ISO639-1] when possible.)

The value of the File-Date field and of the Added date for each new 
subtag record are set to a date near the date of IESG approval of this 
memo.

2.2.  New subtags

For each language in [ISO639-3] that was not already represented by a 
primary language subtag in the Language Subtag Registry, a new subtag 
was added to the Registry, using the [ISO639-3] code element as the 
value for the Subtag field and the inverted name as the value for the 
Description field.  The following rules were used to determine whether 
to add a primary or extended language subtag:

• If the language was included within a macrolanguage, an extended 
language subtag was added, with the primary language subtag of the 
macrolanguage as the value for the Prefix field.

• If the name of the language included the words “Sign Language”, an 
extended language subtag was added, with the string “sgn” as the value 
for the Prefix field.  This is a special case that treats the existing 
primary language subtag for “Sign Languages” as if it were a 
macrolanguage encompassing all sign languages.  (Note that “sgn” is 
defined as a “collection code” by [ISO639-3] and hence not included in 
that standard.)

• Otherwise, a primary language subtag was added.

As a special case, the code elements “diq” (Dimli) and “kiu” (Kirmanjki) 
were added as extended language subtags, with “zza” as their 
Preferred-Value, even though [iso-dis-639-3_20060421] did not include an 
entry for code element “zza” (because it was released before “zza” was 
added to [ISO639-2]).

All subtags were added to the Registry maintaining alphabetical order 
within each type of tag: all “language” subtags first, followed by all 
“extlang” subtags.  No existing records were moved.

For consistency with naming changes that were reported to have been 
implemented in [ISO639-3], but were not yet present in 
[iso-dis-639-3_20060421], the following additional transformations were 
applied to language names before applying them as Description fields:

• If the name listed in [ISO639-3] included the substring “(generic)”, 
the substring and preceding space were deleted.

• If the name included the substring “(specific)”, the substring was 
replaced by the string “(macrolanguage)”.  The sole exception to this 
rule was “Zande (specific)”, which was left unchanged because a primary 
language subtag for “Zande” already existed and neither was a 
macrolanguage.

2.3.  Modified subtags

For each language in [ISO639-3] that was already represented by a 
primary language subtag in the Language Subtag Registry, but whose name 
in [iso-dis-639-3_20060421] did not exactly match the value for one of 
the Description fields of that subtag, the name from 
[iso-dis-639-3_20060421] was added as a new Description field after the 
existing Description fields.  This principle was followed even when the 
only difference between the names was that one was inverted and the 
other was not, or that one contained a country name or other string in 
parentheses (to distinguish it from another language of the same name) 
and the other did not.

Names from [iso-dis-639-3_20060421] were transformed as listed in 
Section 2.2.  If the resulting name after the transformation exactly 
matched an existing Description field, it was not added.

No existing Description fields were changed or deleted.  As a special 
case, the capitalization of the Subtag field for redundant tag “yi-latn” 
was changed to “yi-Latn”, for consistency with the capitalization 
conventions described in [draft-4646bis], Section 2.1.

2.4.  Grandfathered and redundant tags

As stated in [draft-4646bis], “grandfathered” and “redundant” tags are 
complete tags in the Language Subtag Registry that were registered under 
[RFC1766] or [RFC3066] and remain valid.  Grandfathered tags cannot be 
generated from a combination of valid subtags, while “redundant” tags 
can.

Under certain conditions, registration of a subtag under [draft-4646bis] 
may cause a grandfathered tag to be reclassified as redundant.  It may 
also enable the creation of a generative tag with the same meaning as a 
grandfathered or redundant tag; in that case, the grandfathered or 
redundant tag is marked as Deprecated, and the generative tag (including 
the new subtag) becomes its Preferred-Value.

As a result of adding the new subtags in this update, the following 
grandfathered tags became composable and were reclassified as redundant:

• zh-cmn
• zh-cmn-Hans
• zh-cmn-Hant
• zh-gan
• zh-wuu
• zh-yue

The following grandfathered tags were deprecated, with the indicated 
generative tag serving as the Preferred-Value:

• i-ami (Preferred-Value: ami)
• i-bnn (Preferred-Value: bnn)
• i-pwn (Preferred-Value: pwn)
• i-tao (Preferred-Value: tao)
• i-tay (Preferred-Value: tay)
• i-tsu (Preferred-Value: tsu)
• sgn-CH-de (Preferred-Value: sgn-sgg)
• zh-hakka (Preferred-Value: zh-hak)
• zh-min (no Preferred-Value; see below)
• zh-min-nan (Preferred-Value: zh-nan)
• zh-xiang (Preferred-Value: zh-hns)

The tag “zh-min” is a special case: it represents a small class of 
languages, but is not a true macrolanguage.  It could not ever become a 
generative tag since the [ISO639-3] code element “min” is assigned to an 
individual language (Minangkabau) that is not related to Chinese (“zh”). 
Because it does not represent a useful linguistic distinction for 
tagging purposes, It was deprecated without a Preferred-Value.

The following redundant sign-language tags were deprecated, with the 
indicated generative tag serving as the Preferred-Value:

• sgn-BR (Preferred-Value: sgn-bzs)
• sgn-CO (Preferred-Value: sgn-csn)
• sgn-DE (Preferred-Value: sgn-gsg)
• sgn-DK (Preferred-Value: sgn-dsl)
• sgn-ES (Preferred-Value: sgn-ssp)
• sgn-FR (Preferred-Value: sgn-fsl)
• sgn-GB (Preferred-Value: sgn-bfi)
• sgn-GR (Preferred-Value: sgn-gss)
• sgn-IE (Preferred-Value: sgn-isg)
• sgn-IT (Preferred-Value: sgn-ise)
• sgn-JP (Preferred-Value: sgn-jsl)
• sgn-MX (Preferred-Value: sgn-mfs)
• sgn-NI (Preferred-Value: sgn-ncs)
• sgn-NL (Preferred-Value: sgn-dse)
• sgn-NO (Preferred-Value: sgn-nsl)
• sgn-PT (Preferred-Value: sgn-psr)
• sgn-SE (Preferred-Value: sgn-swl)
• sgn-US (Preferred-Value: sgn-ase)
• sgn-ZA (Preferred-Value: sgn-sfs)

A Comments field was added to each of the deprecated grandfathered and 
redundant tags, with a value in the form:

“replaced by ISO code xxx”

where “xxx” represents the new primary or extended language subtag 
(derived from [ISO639-3]) that caused the tag to become deprecated.  A 
similar comment was exceptionally added to the entry for the 
grandfathered tag “zh-guoyu”, which was already deprecated.  These 
comments were added for consistency with other grandfathered tags in the 
Registry.

No change was made to the Description field(s) for any of the 
grandfathered or redundant tags.  For example, the redundant tag 
 “sgn-US” continues to carry the Description “American Sign Language”. 
The sign language tags registered prior to [RFC4646] remain an exception 
to the general principle that the meaning of a non-grandfathered tag can 
be derived from its component subtags.

3.  Updated Registry Contents

The remainder of this section specified the updated set of records for 
the Language Subtag Registry.  This material was deleted before 
publication of this memo, to avoid any potential confusion with the 
Registry itself. The IANA Language Subtag Registry can be found at 
http://www.iana.org/numbers.html under "Language Tags."

[RFC EDITOR NOTE: the remainder of this section is to be deleted upon 
publication.]

The updated contents of the Language Subtag Registry follow.  This data 
is intended as a complete replacement for the current contents of the 
Registry.  The Registry begins with the line that starts with the string 
"File-Date" and continues to the end of this section. Headers, footers, 
line breaks, and other vertical whitespace introduced by the RFC process 
are not significant. Leading horizontal whitespace relative to the 
"File-Date" line indicates a continued line in the record-jar format, 
and must not be deleted.

<<insert Registry contents here>>

4.  Security Considerations

This document specifies the complete updated contents to be used by IANA 
in populating the Language Subtag Registry.  For security considerations 
relevant to the Registry and the use of language tags, see 
[draft-4646bis].

5.  IANA Considerations

In its initial phase as an Internet-Draft, this memo contained the 
complete updated contents of the Language Subtag Registry.  As an RFC, 
it contains a pointer to the updated content for the Registry, which is 
maintained by IANA.  The Language Subtag Registry can be found at 
<http://www.iana.org/numbers.html> under “Language Tags”.  For details 
on the procedures for the format and ongoing maintenance of this 
Registry, see [draft-4646bis].

-----8<-----cut here-----8<-----cut here-----8<-----cut here-----8<-----

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru