Subject: [Ltru] Begin LTRU WG last call on 4646bis and 4645bis

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Feb 2008 16:40:57 -0800

Hi -

After consulting with our document editors, my co-chair, and our
Area Director, as ltru co-chair I'm pleased to announce the start
of working group last call on two documents:
http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-11.txt
http://www.ietf.org/internet-drafts/draft-ietf-ltru-4645bis-04.txt

This will be a two-week WG last call, ending on February 22.
In order to maintain some semblance of sanity PLEASE:
   1) group your *purely* editorial comments into a single message
   2) technical comments should be posted with *ONE* issue per message
   3) the subject line should identify the document (e.g. 4646bis)
   4) the subject line should uniquely identify the issue
   5) if there is an issue which you believe has not been satisfactorily
      resolved, or needs to be reconsidered in light of experience,
      NOW is the time to speak up!
   6) comments of the form "I've read this document and have no problems
      with it" are also helpful.
   7) in discussing comments, if a new issue arises, USE A NEW SUBJECT
      LINE

Please post your comments to to [email-masked]

February 25 is the i-d cutoff.  We hope to be able to issue updated
drafts reflecting the working group last call comments before then.
Depending on the nature of the comments and the edits, at that time
we will either issue a second last call, to end March 17 (extended
due to the IETF meeting in Philadelphia), or hand the documents to
our ADs.

Randy
ltru co-chair

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

---

From: Addison Phillips <[email-masked]>
Date: Fri, 08 Feb 2008 17:10:46 -0800

> After consulting with our document editors,

I don't recall seeing a note from you recently, but I'll go back and 
look for it. Shouldn't I submit draft-12, with its one or two edits first?

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Feb 2008 17:35:24 -0800

Hi -

> From: "Addison Phillips" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Friday, February 08, 2008 5:10 PM
> Subject: Re: [Ltru] Begin LTRU WG last call on 4646bis and 4645bis
>
> look for it.

A short while ago I received a NDN for you.  Sorry, I assumed you'd
seen our conversation.

> Shouldn't I submit draft-12, with its one or two edits first?

No.  If it's just one or two (or even a small handful of) edits,
let's treat them individually as WGLC comments.

Randy

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 Feb 2008 09:45:28 +0100

On Fri, Feb 08, 2008 at 04:40:57PM -0800,
 Randy Presuhn <[email-masked]> wrote 
 a message of 38 lines which said:

> working group last call on two documents:

Some purely editorial comments:

1) The most important: "extended language subtags" or similar
expressions appear in a lot of places despite extlang removal. Do we
agree they should all be suppressed? (See for instance "Codes assigned
by ISO 639-2 that do not conflict with existing three-letter primary
or extended language subtags are entered into the IANA registry" or
"Extension subtags MUST follow all language, extended language,
script, region, and variant subtag" or, worse, "Extended language
subtags MUST include exactly one 'Prefix' field".)

2) Now that extended language subtags are obsolete (before being
used), do we want to retain the "primary language" terminology? It is
a bit strange that we talk about "primary language subtags" while
there is no secondary language subtags anymore. May be a 's/primary
language subtag/language subtag/g' everywhere?

3) In 2.2.2 "Extended Language Subtags", add a reference to 2.2.9
"Classes of Conformance" because of the discussion on the 'extlang'
production in 2.2.9. I suggest at the end of 2.2.2 "See also 2.2.9 for
a discussion of the consequences of this decision on the grammar."

4) In 8, "It also permanently reserves and disallows the use of
extlang subtags.  The changes necessary to achieve this were:
* something". Replace "something" by:

* New ABNF grammar excluding the "extlang" production (see 2.2.9)
* New Macrolanguage field (see 3.1.9)

5) All references to RFC 4234 should be replaced by references to RFC
5234 (no consequences for us since we do not use LWSP)

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 13 Feb 2008 10:17:10 -0800

> subtags MUST include exactly one 'Prefix' field".)

+1

> language subtag/language subtag/g' everywhere?

I'm of two minds about this. Formally, that's true, but it may be worth
retaining the 'primary' because one could think of a language tag as being
composed of a sequence of "language subtags". We don't, but someone could.
So it might be worth retaining the 'primary' for clarity.

> a discussion of the consequences of this decision on the grammar."

+1

> * New Macrolanguage field (see 3.1.9)

+1

> 5234 (no consequences for us since we do not use LWSP)

0

-- 
Mark

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 Feb 2008 23:07:59 +0100

On Wed, Feb 13, 2008 at 10:17:10AM -0800,
 Mark Davis <[email-masked]> wrote 

> > 5234 (no consequences for us since we do not use LWSP)

Why? What's the problem with RFC 5234?
_______________________________________________
Ltru mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 13 Feb 2008 15:32:28 -0800

0 meaning no opinion (not familiar with the situation)

-1 would mean disagree.

Mark

---

From: Martin Duerst <[email-masked]>
Date: Thu, 14 Feb 2008 16:16:28 +0900

As a technical contributor, +1 for replacing RFC 4234 with RFC 5234,
because the later is an update of the former.

Regards,    Martin.

At 08:32 08/02/14, Mark Davis wrote:
>On Feb 13, 2008 2:07 PM, Stephane Bortzmeyer <<mailto:[email-masked]>[email-masked]> wrote:
>> Mark Davis <<mailto:[email-masked]>[email-masked]> wrote

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 14 Feb 2008 17:58:53 +0100

On Wed, Feb 13, 2008 at 09:45:28AM +0100,
 Stephane Bortzmeyer <[email-masked]> wrote 
 a message of 44 lines which said:

> agree they should all be suppressed? (See for instance "Codes
> assigned by ISO 639-2 that do not conflict with existing
> three-letter primary or extended language subtags are entered into
> the IANA registry" or "Extension subtags MUST follow all language,
> extended language, script, region, and variant subtag" or, worse,
> "Extended language subtags MUST include exactly one 'Prefix'
> field".)

Since I believe that this issue is the least controversial, here is a
diff against -11 that implements it. Sorry, I had to delete an entire
example (zh-gan) which worked only for extlangs.)

--- draft-ietf-ltru-4646bis-11.xml.orig	2008-02-14 16:13:21.723195266 +0100
+++ draft-ietf-ltru-4646bis-11.xml	2008-02-14 17:52:56.796669835 +0100
@@ -410,7 +410,7 @@
         <t>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'.</t>
-        <t>Extension subtags MUST follow all language, extended language, script,
+        <t>Extension subtags MUST follow all language, script,
         region, and variant subtags in a tag.</t>
         <t>All subtags following the singleton and before another singleton
         are part of the extension. Example: In the tag "fr-a-Latn", the subtag
@@ -429,7 +429,7 @@
      <t><list style="numbers">
         <t>Private use subtags are separated from the other subtags 
         defined in this document by the reserved single-character subtag 'x'.</t><t>Private use subtags MUST conform to the format and content constraints defined in the ABNF for all subtags.</t>
-        <t>Private use subtags MUST follow all language, extended language, 
+        <t>Private use subtags MUST follow all 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 
@@ -449,7 +449,7 @@
   </section>
   
 <section title="Classes of Conformance" anchor="conformance">
-<t>Implementations sometimes need to describe their capabilities with regard to the rules and practices described in this document. Tags can be checked or verified in a number of ways, but two particular classes of tag conformance are formally defined here.</t><t>A tag is considered "well-formed" if it conforms to the <xref target="syntax">ABNF</xref>. Note that irregular grandfathered tags are now listed in the 'irregular' production. </t><t>A tag is considered "valid" if it well-formed and it also satisfies these conditions:<list style="symbols"><t>The tag is either a grandfathered tag, or all of its language, extended language, script, region, and variant subtags appear in the IANA language subtag registry as of the particular registry date.</t><t>There are no duplicate singleton (extension) subtags and no duplicate variant subtags.</t><t>For each subtag that has a 'Prefix' field in the registry, the Prefix matches the language tag using <xref target="RFC4647">Extended Filtering</xref>. That is, each subtag in the Prefix is present in the tag and in the same order. Furthermore, all of the Prefix's subtags MUST appear before the subtag. For example, the Prefix "zh-TW" matches the tag "zh-Hant-TW".</t></list></t>
+<t>Implementations sometimes need to describe their capabilities with regard to the rules and practices described in this document. Tags can be checked or verified in a number of ways, but two particular classes of tag conformance are formally defined here.</t><t>A tag is considered "well-formed" if it conforms to the <xref target="syntax">ABNF</xref>. Note that irregular grandfathered tags are now listed in the 'irregular' production. </t><t>A tag is considered "valid" if it well-formed and it also satisfies these conditions:<list style="symbols"><t>The tag is either a grandfathered tag, or all of its language, script, region, and variant subtags appear in the IANA language subtag registry as of the particular registry date.</t><t>There are no duplicate singleton (extension) subtags and no duplicate variant subtags.</t><t>For each subtag that has a 'Prefix' field in the registry, the Prefix matches the language tag using <xref target="RFC4647">Extended Filtering</xref>. That is, each subtag in the Prefix is present in the tag and in the same order. Furthermore, all of the Prefix's subtags MUST appear before the subtag. For example, the Prefix "zh-TW" matches the tag "zh-Hant-TW".</t></list></t>
 <t>Note that a tag's validity depends on the date of the registry used to validate the tag. A more-recent copy of the registry might contain a subtag that an older version does not.</t><t>A tag is considered "valid" for a given <xref target="extensions">extension</xref> (as of a particular version, revision, and date) if it meets the criteria for "valid" above and also satisfies this condition:<list><t>Each subtag used in the extension part of the tag is valid according to the extension.</t></list></t>        

@@ -567,7 +567,7 @@
 <t>Values in the field 'Prefix' in records of type 'variant' MAY be modified, so long as the modifications broaden the set of prefixes. That is, a prefix MAY be replaced by one of its own prefixes. For example, the prefix "en-US" could be replaced by "en", but not by the prefixes "en-Latn", "fr", or "en-US-boont". If one of those prefixes were needed, a new Prefix SHOULD be registered.</t>
 <t>Values in the field 'Prefix' MUST NOT be removed.</t>
 <t>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.</t><t>The field 'Suppress-Script' MAY be added or removed via the registration process.</t><t>The field 'Macrolanguage' MAY be added or removed via the registration process, but only in response to changes made by ISO 639. The Macrolanguage field appears whenever a language has a corresponding Macrolanguage in ISO 639. That is, the macrolanguage fields in the registry exactly match those of ISO 639. No other macrolanguage mappings will be considered for registration. </t>
-<t>Codes assigned by ISO 639-1 that do not conflict with existing two-letter primary language subtags and which have no corresponding three-letter primary or extended language subtags defined in the registry are entered into the IANA registry as new records of type 'language'.</t><t>Codes assigned by ISO 639-2 that do not conflict with existing three-letter primary or extended language subtags are entered into the IANA registry as new records of type 'language'.</t><t>Codes assigned by ISO 639-3 that do not conflict with existing three-letter primary language subtags are entered into the IANA registry as new primary language records.  </t><t>Codes assigned by ISO 15924 and ISO 3166 that do not conflict with existing subtags of the associated type and whose meaning is not the same as an existing subtag of the same type are entered into the IANA registry as new records.</t><t>Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are withdrawn by their respective maintenance or registration authority remain valid in language tags. A 'Deprecated' field containing the date of withdrawal MUST be added to the record. If a new record of the same type is added that represents a replacement value, then a 'Preferred-Value' field MAY also be added. The registration process MAY be used to add comments about the withdrawal of the code by the respective standard.      
+<t>Codes assigned by ISO 639-1 that do not conflict with existing two-letter primary language subtags and which have no corresponding three-letter primary subtag defined in the registry are entered into the IANA registry as new records of type 'language'.</t><t>Codes assigned by ISO 639-2 that do not conflict with existing three-letter primary subtag are entered into the IANA registry as new records of type 'language'.</t><t>Codes assigned by ISO 639-3 that do not conflict with existing three-letter primary language subtags are entered into the IANA registry as new primary language records.  </t><t>Codes assigned by ISO 15924 and ISO 3166 that do not conflict with existing subtags of the associated type and whose meaning is not the same as an existing subtag of the same type are entered into the IANA registry as new records.</t><t>Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are withdrawn by their respective maintenance or registration authority remain valid in language tags. A 'Deprecated' field containing the date of withdrawal MUST be added to the record. If a new record of the same type is added that represents a replacement value, then a 'Preferred-Value' field MAY also be added. The registration process MAY be used to add comments about the withdrawal of the code by the respective standard.      
 <list style="hanging"><t hangText="Example">The region code 'TL' was assigned to the country 'Timor-Leste', replacing the code 'TP' (which was assigned to 'East Timor' when it was under administration by Portugal). The subtag 'TP' remains valid in language tags, but its record contains the a 'Preferred-Value' of 'TL' and its field 'Deprecated' contains the date the new code was assigned ('2004-07-06').</t></list></t><t>Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict with existing subtags of the associated type, including subtags that are deprecated, MUST NOT be entered into the registry. The following additional considerations apply to subtag values that are reassigned:
 <list style="letters">
 
@@ -600,10 +600,7 @@
       then the field 'Type' in that record is changed from 'grandfathered' to '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, this document caused the ISO 639-3 code 'gan', used
-      in the redundant tag "zh-gan", to be registered as an extended language 
-      subtag. The formerly-grandfathered tag "zh-gan" became a redundant tag as a result (but
-      existing content or implementations that use "zh-gan" remain valid).</t>
+      match valid generative subtag sequences. </t>
 </list></t><t>Note: The redundant and grandfathered entries together are the complete list of tags registered under <xref target="RFC3066"></xref>. The redundant tags are those that can now be formed using the subtags defined in the registry together with the rules of  <xref target="sources"></xref>. The grandfathered entries include those that can never be legal under those same provisions plus those tags that contain subtags not yet registered or, perhaps, inappropriate for registration. </t><t>The set of redundant and grandfathered tags is permanent and stable: new entries in this section MUST NOT be added and existing entries MUST NOT be removed. Records of type 'grandfathered' MAY have their type converted to 'redundant'; see item 12 in <xref target="possibleReg"></xref> for more information. The decision-making process about which tags were initially grandfathered and which were made redundant is described in <xref target="RFC4645"></xref>.</t><t>RFC 3066 tags that were deprecated prior to the adoption of <xref target="RFC4646"></xref> are part of the list of grandfathered tags, and their component subtags were not included as registered variants (although they remain eligible for registration). For example, the tag "art-lojban" was deprecated in favor of the language subtag 'jbo'.</t></section><section anchor="registrationProc" title="Registration Procedure for Subtags">
 <t>The procedure given here MUST be used by anyone who wants to use a subtag not currently in the IANA Language Subtag Registry.</t>
 <t>Only subtags of type 'language' and 'variant' will be considered for independent 
@@ -647,7 +644,7 @@
 <t>Some fields in both the registration form as well as the registry record itself permit the use of non-ASCII characters. Registration requests SHOULD use the UTF-8 encoding for consistency and clarity. However, since some mail clients do not support this encoding, other encodings MAY be used for the registration request. The Language Subtag Reviewer is responsible for ensuring that the proper Unicode characters appear in both the archived request form and the registry record. In the case of a transcription or encoding error by IANA, the Language Subtag Reviewer will request that the registry be repaired, providing any necessary information to assist IANA.</t><t>Variant subtags are usually registered for use with a particular range of language tags. For example, the subtag 'rozaj' is 
 intended for use with language tags that start with the primary language subtag "sl", since 
 Resian is a dialect of Slovenian. Thus, the subtag 'rozaj' would be appropriate in tags such as "sl-Latn-rozaj" or
-"sl-IT-rozaj". This information is stored in the 'Prefix' field in the registry. Variant registration requests SHOULD include at least one 'Prefix' field in the registration form.</t><t>Extended language subtags MUST include exactly one 'Prefix' field.</t>
+"sl-IT-rozaj". This information is stored in the 'Prefix' field in the registry. Variant registration requests SHOULD include at least one 'Prefix' field in the registration form.</t>
 
 <t>The 'Prefix' field for a given registered subtag exists 
 in the IANA registry as a guide to usage. Additional prefixes MAY be added by filing an additional registration form. In that form, the "Any other 
@@ -903,7 +900,7 @@
 </section><section anchor="length" title="Length Considerations"><t>There is no defined upper limit on the size of language tags. While historically most language tags have consisted of language and region subtags with a combined total length of up to six characters, larger tags have always been both possible and actually appeared in use. </t><t>Neither the language tag syntax nor other requirements in this document impose a fixed upper limit on the number of subtags in a language tag (and thus an upper bound on the size of a tag). The language tag syntax suggests that, depending on the specific language, more subtags (and thus a longer tag) are sometimes necessary to completely identify the language for certain applications; thus, it is possible to envision long or complex subtag sequences. </t><section anchor="bufferLimits" title="Working with Limited Buffer Sizes"><t>Some applications and protocols are forced to allocate fixed buffer sizes or otherwise limit the length of a language tag. A conformant implementation or specification MAY refuse to support the storage of 
 language tags
 that exceed a specified length. Any such limitation SHOULD be clearly documented, and such documentation SHOULD include what happens to longer tags (for example, whether an error value is generated or the language tag is truncated). A protocol that allows tags to be truncated at an arbitrary limit, without giving any indication of what that limit is, has the potential for causing harm by changing the meaning of tags in substantial ways. </t><t>In practice, most language tags do not require more than a few subtags and will not approach reasonably sized buffer limitations; see <xref target="choice"></xref>.</t><t>Some specifications or protocols have limits on tag length but do not have a fixed length limitation. For example, <xref target="RFC2231"></xref>  has no explicit length limitation: the length available for the language tag is constrained by the length of other header components (such as the charset's name) coupled with the 76-character limit in <xref target="RFC2047"></xref>. Thus, the "limit" might be 50 or more characters, but it could potentially be quite small.</t><t>The considerations for assigning a buffer limit are:<list><t>Implementations SHOULD NOT truncate language tags unless the meaning of the tag is purposefully being changed, or unless the tag does not fit into a limited buffer size specified by a protocol for storage or transmission.</t><t>Implementations SHOULD warn the user when a tag is truncated since truncation changes the semantic meaning of the tag.</t><t>Implementations of protocols or specifications that are space constrained but do not have a fixed limit SHOULD use the longest possible tag in preference to truncation.</t><t>Protocols or specifications that specify limited buffer sizes for language tags MUST allow for language tags of up to 33 characters.</t><t>Protocols or specifications that specify limited buffer sizes for language tags SHOULD allow for language tags of at least
-30 characters. Note that <xref target="RFC4646">RFC 4646</xref> recommended a field size of 42 character because it included the permanently reserved (and unused) 'extlang' production. The current size recommendation does not include the use of the 'extlang' field. </t></list></t><t>The following illustration shows how the 30-character recommendation was derived. The combination of language and extended language subtags was chosen for future compatibility. At up to 15 characters, this combination is longer than the longest possible primary language subtag (8 characters):</t><figure title="Derivation of the Limit on Tag Length" anchor="longtag42"><artwork>
+30 characters. Note that <xref target="RFC4646">RFC 4646</xref> recommended a field size of 42 character because it included the permanently reserved (and unused) 'extlang' production. The current size recommendation does not include the use of the 'extlang' field. </t></list></t><t>The following illustration shows how the 30-character recommendation was derived. The combination of language subtags was chosen for future compatibility. At up to 15 characters, this combination is longer than the longest possible primary language subtag (8 characters):</t><figure title="Derivation of the Limit on Tag Length" anchor="longtag42"><artwork>
 language      =  3 (ISO 639-2; ISO 639-1 requires 2)
 script        =  5 (if not suppressed: see Section 4.1)
 region        =  4 (UN M.49; ISO 3166 requires 3)
_______________________________________________
Ltru mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 20 Feb 2008 11:22:32 +0100

>       with it" are also helpful.

I've read and reviewed the version -11 of the 4646bis draft in detail,
and implemented it, starting from my RFC 4646 implementation
(http://www.bortzmeyer.org/gabuzomeu-parsing-language-tags.html).
GaBuZoMeu has automatic testing of test sets (see
http://www.langtag.net/test-suites.html) and of the registry, which
allows detailed testing of the implementation. 

From this experience, I can say that:

* as already discussed on this list, the "irregular" production in the
ABNF needs to be extended :-) with the grandfathered tags that used
extlangs.

* test sets need to be modified to remove extlangs from the set of
"well-formed but invalid" tags. "fr-foo" was well-formed, it is no
longer.

* the changes to accomodate 4646bis are minimal: the new ABNF is much
better and the Macrolanguage field is simple to handle and to test
(unlike the Prefix field, it can only store a language subtag). The
switch to UTF-8 was painful for my host language, which has no
standard library to read UTF-8 files :-( But there are several
existing non-standard libraries.

GaBuZoMeu version 2 (4646bis) now runs 100 % of its test suite. To me,
it is an indication that 4646bis, as of version -11, is an usable
specification.

Is there similar experience from the other implementors?
_______________________________________________
Ltru mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 20 Feb 2008 11:41:06 +0100

> Some purely editorial comments:

Here is a patch against -11 (I was not able to find a XML source for
the editor's copy) . I incorporated all the changes explained in
http://www.ietf.org/mail-archive/web/ltru/current/msg09419.html
*except* the removal of "primary language subtag", following Mark
Davis's uncertainty
(http://www.ietf.org/mail-archive/web/ltru/current/msg09434.html).

I added also the missing "former extlang" grandfathered tags in the
"irregular" production of the ABNF.
--- draft-ietf-ltru-4646bis-11.xml.orig	2008-02-20 11:27:49.000000000 +0100
+++ draft-ietf-ltru-4646bis-11.xml	2008-02-20 11:34:41.000000000 +0100
@@ -19,7 +19,7 @@
 <!ENTITY rfc3339 SYSTEM "./rfcrefs/reference.RFC.3339.xml">
 <!ENTITY rfc3552 SYSTEM "./rfcrefs/reference.RFC.3552.xml">
 <!ENTITY rfc3629 SYSTEM "./rfcrefs/reference.RFC.3629.xml">
-<!ENTITY rfc4234 SYSTEM "./rfcrefs/reference.RFC.4234.xml">
+<!ENTITY rfc5234 SYSTEM "./rfcrefs/reference.RFC.5234.xml">
 ]>
 <?rfc toc='yes' symrefs='yes' sortrefs='yes'?><rfc ipr="full3978" docName="draft-ietf-ltru-4646bis-11" category="bcp" obsoletes="4646">
 <front>
@@ -80,7 +80,7 @@
    </section>
 <section title="The Language Tag" anchor="langtag"><t>Language tags are used to help identify languages, whether spoken, written, signed, or otherwise signaled, for the purpose of communication. This includes constructed and artificial languages, but excludes languages not intended primarily for human communication, such as programming languages.</t>
   <section title="Syntax" anchor="syntax">
-    <t>The language tag is composed of one or more parts, known as "subtags". Each subtag consists of a sequence of alphanumeric characters. Subtags are distinguished and separated from one another by a hyphen ("-", ABNF <xref target="RFC4234"></xref> %x2D). A language tag consists of a "primary language" subtag and 
+    <t>The language tag is composed of one or more parts, known as "subtags". Each subtag consists of a sequence of alphanumeric characters. Subtags are distinguished and separated from one another by a hyphen ("-", ABNF <xref target="RFC5234"></xref> %x2D). A language tag consists of a "primary language" subtag and 
     a (possibly empty) series of subsequent subtags, each of which refines or narrows the range of languages identified by the overall tag.</t><t>Usually, each type of subtag is distinguished by 
     length, position in the tag, and content: subtags can be recognized solely by these features. The only exception to this is a fixed list of grandfathered tags registered under <xref target="RFC3066">RFC 3066</xref>. This makes it possible 
     to construct a parser that can extract and assign some semantic information 
@@ -88,7 +88,7 @@
     parser need not have an up-to-date copy (or any copy at all) of the subtag registry to
     perform most searching and matching operations.</t>
     <figure anchor="ABNF" title="Language Tag ABNF">
-    <preamble>The syntax of the language tag in ABNF <xref target="RFC4234"></xref> is:</preamble>
+    <preamble>The syntax of the language tag in ABNF <xref target="RFC5234"></xref> is:</preamble>
     <artwork type="abnf" name="abnf.text">
 Language-Tag  = langtag
               / privateuse             ; private use tag
@@ -122,11 +122,13 @@
 
 privateuse    = "x" 1*("-" (1*8alphanum))
 
-irregular     = "en-GB-oed" / "i-ami" / "i-bnn" / "i-default"
-              / "i-enochian" / "i-hak" / "i-klingon" / "i-lux" 
-              / "i-mingo" / "i-navajo" / "i-pwn" / "i-tao" 
-              / "i-tay" / "i-tsu" / "sgn-BE-fr" / "sgn-BE-nl" 
-              / "sgn-CH-de" 
+irregular     = "en-GB-oed" / "i-ami" / "i-bnn" / "i-default"                 
+                / "i-enochian" / "i-hak" / "i-klingon" / "i-lux"                 
+                / "i-mingo" / "i-navajo" / "i-pwn" / "i-tao"                 
+                / "i-tay" / "i-tsu" / "no-bok" / "no-nyn"                 
+                / "sgn-BE-fr" / "sgn-BE-nl" / "sgn-CH-de" 
+                / "zh-cmn" / "zh-cmn-Hans" / "zh-cmn-Hant" / "zh-gan"                 
+                / "zh-min" / "zh-min-nan" / "zh-wuu" / "zh-yue"
 
 alphanum      = (ALPHA / DIGIT)       ; letters and numbers
 </artwork>
@@ -149,7 +151,7 @@
     However, in the tags defined by this document, the uppercase US-ASCII letters in the range 'A' through 'Z' are considered equivalent and mapped directly to their US-ASCII lowercase equivalents in the range 'a' through 'z'. Thus, the tag "mn-Cyrl-MN" is not
     distinct from "MN-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.</t><t>Although case distinctions do not carry meaning in language tags, consistent formatting and presentation of the tags will aid users. The format of the tags and subtags in the registry is RECOMMENDED. In this format, all non-initial two-letter subtags are uppercase, all non-initial four-letter subtags are titlecase, and all other subtags are lowercase.</t><t>Note that although <xref target="RFC4234"></xref> refers to octets,
+    Cyrillic script as used in Mongolia.</t><t>Although case distinctions do not carry meaning in language tags, consistent formatting and presentation of the tags will aid users. The format of the tags and subtags in the registry is RECOMMENDED. In this format, all non-initial two-letter subtags are uppercase, all non-initial four-letter subtags are titlecase, and all other subtags are lowercase.</t><t>Note that although <xref target="RFC5234"></xref> refers to octets,
     the language tags described in this document are sequences of characters
     from the US-ASCII <xref target="ISO646"></xref> repertoire. Language tags MAY be used in documents and
     applications that use other encodings, so long as these encompass the US-ASCII
@@ -290,7 +292,7 @@
            </t> 
 
 </section><section anchor="extlang" title="Extended Language Subtags"><!-- extended language -->         
-<t>Extended language subtags are permanently reserved. They MUST NOT be registered or used to form language tags (except in grandfathered tags). They were originally created to allow for certain kinds of compatibility mappings which ultimately were not used.</t>
+<t>Extended language subtags are permanently reserved. They MUST NOT be registered or used to form language tags (except in grandfathered tags). They were originally created to allow for certain kinds of compatibility mappings which ultimately were not used. Tags using them are no longer well-formed, see <xref target="conformance"/> for a discussion of the consequences of this decision on the grammar.</t>
         
 </section><section anchor="script" title="Script Subtag"><!-- script -->        
 
@@ -410,7 +412,7 @@
@@ -429,7 +431,7 @@
@@ -449,7 +451,7 @@
   </section>

@@ -483,7 +485,7 @@
    the process described in <xref target="registrationProc"/>. The existing registration forms for grandfathered and redundant tags taken from RFC 3066 will be maintained as part of the obsolete RFC 3066 registry. The remaining set of subtags created by either <xref target="RFC4645"></xref> or <xref target="registry-update"></xref> will not have registration forms created for them.</t>
    <section title="File Format" anchor="fileformat"><t>The registry consists of a series of records stored in the record-jar format (described in <xref target="record-jar"></xref>). Each record, in turn, consists of a series of fields that describe the various subtags and tags. The registry is a  <xref target="Unicode">Unicode</xref> text file, using the <xref target="RFC3629">UTF-8</xref> character encoding.</t><t> Each field can be considered a single, logical line of <xref target="Unicode">Unicode</xref>  characters,  comprising a field-name and a field-body separated by a COLON character (%x3A).
         Each field is terminated by the newline sequence CRLF. The text in each field MUST be in Unicode Normalization Form C (NFC).</t><t>A collection of fields forms a 'record'. Records are separated by lines containing only the sequence "%%" (%x25.25). </t><t>Although fields are logically a single line of text, each line of text in the file format is limited to 72 bytes in length. To accommodate this, the field-body can be split into a multiple-line representation; this
-        is called "folding". Folding is always done on Unicode default grapheme boundaries (that is, never in the middle of a multibyte UTF-8 sequence nor in the middle of a combining character sequence). </t><t>Although the file format uses the UTF-8 encoding, unless otherwise indicated, fields are restricted to the printable characters from the <xref target="ISO646">US-ASCII</xref> repertoire.</t><t>The format of the registry is described by the following ABNF (per <xref target="RFC4234"></xref>):  </t><figure title="Registry Format ABNF" anchor="record-jar-fig"> <artwork type="ABNF" name="record-jar">
+        is called "folding". Folding is always done on Unicode default grapheme boundaries (that is, never in the middle of a multibyte UTF-8 sequence nor in the middle of a combining character sequence). </t><t>Although the file format uses the UTF-8 encoding, unless otherwise indicated, fields are restricted to the printable characters from the <xref target="ISO646">US-ASCII</xref> repertoire.</t><t>The format of the registry is described by the following ABNF (per <xref target="RFC5234"></xref>):  </t><figure title="Registry Format ABNF" anchor="record-jar-fig"> <artwork type="ABNF" name="record-jar">
 registry   = record *("%%" CRLF record)
 record     = 1*( field-name *SP ":" *SP field-body CRLF )
 field-name = (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)]
@@ -567,7 +569,7 @@
 <t>Values in the field 'Prefix' in records of type 'variant' MAY be modified, so long as the modifications broaden the set of prefixes. That is, a prefix MAY be replaced by one of its own prefixes. For example, the prefix "en-US" could be replaced by "en", but not by the prefixes "en-Latn", "fr", or "en-US-boont". If one of those prefixes were needed, a new Prefix SHOULD be registered.</t>
 <t>Values in the field 'Prefix' MUST NOT be removed.</t>
 <t>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.</t><t>The field 'Suppress-Script' MAY be added or removed via the registration process.</t><t>The field 'Macrolanguage' MAY be added or removed via the registration process, but only in response to changes made by ISO 639. The Macrolanguage field appears whenever a language has a corresponding Macrolanguage in ISO 639. That is, the macrolanguage fields in the registry exactly match those of ISO 639. No other macrolanguage mappings will be considered for registration. </t>
-<t>Codes assigned by ISO 639-1 that do not conflict with existing two-letter primary language subtags and which have no corresponding three-letter primary or extended language subtags defined in the registry are entered into the IANA registry as new records of type 'language'.</t><t>Codes assigned by ISO 639-2 that do not conflict with existing three-letter primary or extended language subtags are entered into the IANA registry as new records of type 'language'.</t><t>Codes assigned by ISO 639-3 that do not conflict with existing three-letter primary language subtags are entered into the IANA registry as new primary language records.  </t><t>Codes assigned by ISO 15924 and ISO 3166 that do not conflict with existing subtags of the associated type and whose meaning is not the same as an existing subtag of the same type are entered into the IANA registry as new records.</t><t>Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are withdrawn by their respective maintenance or registration authority remain valid in language tags. A 'Deprecated' field containing the date of withdrawal MUST be added to the record. If a new record of the same type is added that represents a replacement value, then a 'Preferred-Value' field MAY also be added. The registration process MAY be used to add comments about the withdrawal of the code by the respective standard.      
+<t>Codes assigned by ISO 639-1 that do not conflict with existing two-letter primary language subtags and which have no corresponding three-letter primary subtag defined in the registry are entered into the IANA registry as new records of type 'language'.</t><t>Codes assigned by ISO 639-2 that do not conflict with existing three-letter primary subtag are entered into the IANA registry as new records of type 'language'.</t><t>Codes assigned by ISO 639-3 that do not conflict with existing three-letter primary language subtags are entered into the IANA registry as new primary language records.  </t><t>Codes assigned by ISO 15924 and ISO 3166 that do not conflict with existing subtags of the associated type and whose meaning is not the same as an existing subtag of the same type are entered into the IANA registry as new records.</t><t>Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are withdrawn by their respective maintenance or registration authority remain valid in language tags. A 'Deprecated' field containing the date of withdrawal MUST be added to the record. If a new record of the same type is added that represents a replacement value, then a 'Preferred-Value' field MAY also be added. The registration process MAY be used to add comments about the withdrawal of the code by the respective standard.      
 <list style="hanging"><t hangText="Example">The region code 'TL' was assigned to the country 'Timor-Leste', replacing the code 'TP' (which was assigned to 'East Timor' when it was under administration by Portugal). The subtag 'TP' remains valid in language tags, but its record contains the a 'Preferred-Value' of 'TL' and its field 'Deprecated' contains the date the new code was assigned ('2004-07-06').</t></list></t><t>Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict with existing subtags of the associated type, including subtags that are deprecated, MUST NOT be entered into the registry. The following additional considerations apply to subtag values that are reassigned:
 <list style="letters">
 
@@ -600,10 +602,7 @@
@@ -647,7 +646,7 @@
 
@@ -903,7 +902,7 @@
@@ -1050,7 +1049,7 @@
 
 <t>The specific changes in this document to meet these goals are:
 <list style="symbols">
-<t>Defines the incorporation of ISO 639-3 codes as language. It also permanently reserves and disallows the use of extlang subtags. The changes necessary to achieve this were:<list><t>something</t></list></t><t>Changed the ABNF related to grandfathered tags. The irregular tags are now listed. Well-formed grandfathered tags are now described by the 'langtag' production and the 'grandfathered' production was removed as a result. Also: added description of both types of grandfathered tags to <xref target="preexisreg"></xref>.</t><t>Added the paragraph on "collections" to <xref target="choice"></xref>.</t><t>Changed the capitalization rules for 'Tag' fields in <xref target="ianaformat"></xref>.</t><t>Split section 3.1 up into subsections.</t><t>Modified section 3.5 to allow Suppress-Script fields to be added, modified, or removed via the registration process. This was an erratum from RFC 4646.</t><t>Modified examples that used region code 'CS' (formerly Serbia and Montenegro) to use 'RS' (Serbia) instead.</t><t>Modified the rules for creating and maintaining record 'Description' fields to prevent duplicates, including inverted duplicates.</t><t>Removed the lengthy description of why RFC 4646 was created from this section, which also caused the removal of the reference to XML Schema.</t><t>Modified the text in section 2.1 to place more emphasis on the fact that language tags are not case sensitive.</t><t>Replaced the example "fr-Latn-CA" in Section 2.1 with "sr-Latn-RS" and "az-Arab-IR" because "fr-Latn-CA" doesn't respect the Suppress-Script on 'Latn' with 'fr'.</t><t>Changed the requirements for well-formedness to make singleton repetition checking optional (it is required for validity checking) in <xref target="conformance"></xref>.</t><t>Changed the text in <xref target="conformance"></xref> referring to grandfathered checking to note that the list is now included in the ABNF.</t><t>Modified and added text to <xref target="subtagreviewer"></xref>. The job description was placed first. A note was added making clear that the Language Subtag Reviewer may delegate various non-critical duties, including list moderation. Finally, additional text was added to make the appointment process clear and to clarify that decisions and performance of the reviewer are appealable.</t><t>Added text to <xref target="registrationProc"></xref> clarifying that the ietf-languages list is operated by whomever the IESG appoints.</t><t>Added text to <xref target="descriptionfield"></xref> clarifying that the first Description in a 'language' record matches the corresponding Reference Name for the language in ISO 639-3.</t><t>Modified <xref target="conformance"></xref> to define classes of conformance related to specific tags (formerly 'well-formed' and 'valid' referred to implementations). Notes were added about the removal of 'extlang' from the ABNF provided in RFC 4646, allowing for well-formedness using this older definition. Reference to RFC 3066 well-formedness was also added.</t><t>Added text to the end of <xref target="recordformat"></xref> noting that future versions of this document might add new field types to the Registry format and recommending that implementations ignore any unrecognized fields.</t><t>Added text about what the lack of a Suppress-Script field means in a record to <xref target="suppressfield"></xref>.</t><t>Added text allowing the correction of misspellings and typographic errors to <xref target="descriptionfield"></xref>.</t><t>Added text to <xref target="prefixfield"></xref> disallowing Prefix field conflicts (such as circular prefix references).</t><t>Modified text in <xref target="registrationProc"></xref> to require the subtag reviewer to announce his/her decision (or extension) following the two-week period. Also clarified that any decision or failure to decide can be appealed.</t><t>Modified text in <xref target="choice"></xref> to include the (heretofore anecdotal) guiding principle of tag choice, and clarifying the non-use of script subtags in non-written applications. Also updated examples in this section to use Chamic languages as an example of language collections.</t><t>Prohibited multiple use of the same variant in a tag (i.e. "de-1901-1901"). Previously this was only a recommendation ("SHOULD").</t><t>Removed inappropriate <xref target="RFC2119"></xref> language from the illustration in <xref target="bufferLimits"></xref>.</t><t>Replaced the example of deprecating "zh-gouyu" with "zh-hakka"-&gt;"hak" in <xref target="canonical"></xref>, noting that it was this document that caused the change.</t><t>Replaced the section in <xref target="choice"></xref> dealing with "mul"/"und" to include the subtags 'zxx' and 'mis', as well as the tag "i-default". A normative reference to RFC 2277 was added, along with an informative reference to MARC21.</t><t>Added text to <xref target="registrationProc"></xref> clarifying that any modifications of a registration request must be sent to the ietf-languages list before submission to IANA.</t><t>Changed the ABNF for the record-jar format from using the LWSP production to use a folding whitespace production similar to obs-FWS in <xref target="RFC4234"></xref>. This effectively prevents unintentional blank lines inside a field. </t><t>Clarified and revised text in <xref target="maintreg"></xref>, <xref target="registrationProc"></xref>, and <xref target="iana-subtag-reg"></xref> to clarify that the Language Subtag Reviewer sends the complete registration forms to IANA, that IANA extracts the record from the form, and that the forms must also be archived separately from the registry.</t><t>Added text to <xref target="iana"></xref> requiring IANA to send an announcement to an ietf-languages-announce list whenever the registry is updated.</t>
+<t>Defines the incorporation of ISO 639-3 codes as language. It also permanently reserves and disallows the use of extlang subtags. The changes necessary to achieve this were:<list><t>New ABNF grammar excluding the "extlang" production (see <xref target="conformance"/>).</t><t>New Macrolanguage field (see <xref target="macrolang"/>).</t></list></t><t>Changed the ABNF related to grandfathered tags. The irregular tags are now listed. Well-formed grandfathered tags are now described by the 'langtag' production and the 'grandfathered' production was removed as a result. Also: added description of both types of grandfathered tags to <xref target="preexisreg"></xref>.</t><t>Added the paragraph on "collections" to <xref target="choice"></xref>.</t><t>Changed the capitalization rules for 'Tag' fields in <xref target="ianaformat"></xref>.</t><t>Split section 3.1 up into subsections.</t><t>Modified section 3.5 to allow Suppress-Script fields to be added, modified, or removed via the registration process. This was an erratum from RFC 4646.</t><t>Modified examples that used region code 'CS' (formerly Serbia and Montenegro) to use 'RS' (Serbia) instead.</t><t>Modified the rules for creating and maintaining record 'Description' fields to prevent duplicates, including inverted duplicates.</t><t>Removed the lengthy description of why RFC 4646 was created from this section, which also caused the removal of the reference to XML Schema.</t><t>Modified the text in section 2.1 to place more emphasis on the fact that language tags are not case sensitive.</t><t>Replaced the example "fr-Latn-CA" in Section 2.1 with "sr-Latn-RS" and "az-Arab-IR" because "fr-Latn-CA" doesn't respect the Suppress-Script on 'Latn' with 'fr'.</t><t>Changed the requirements for well-formedness to make singleton repetition checking optional (it is required for validity checking) in <xref target="conformance"></xref>.</t><t>Changed the text in <xref target="conformance"></xref> referring to grandfathered checking to note that the list is now included in the ABNF.</t><t>Modified and added text to <xref target="subtagreviewer"></xref>. The job description was placed first. A note was added making clear that the Language Subtag Reviewer may delegate various non-critical duties, including list moderation. Finally, additional text was added to make the appointment process clear and to clarify that decisions and performance of the reviewer are appealable.</t><t>Added text to <xref target="registrationProc"></xref> clarifying that the ietf-languages list is operated by whomever the IESG appoints.</t><t>Added text to <xref target="descriptionfield"></xref> clarifying that the first Description in a 'language' record matches the corresponding Reference Name for the language in ISO 639-3.</t><t>Modified <xref target="conformance"></xref> to define classes of conformance related to specific tags (formerly 'well-formed' and 'valid' referred to implementations). Notes were added about the removal of 'extlang' from the ABNF provided in RFC 4646, allowing for well-formedness using this older definition. Reference to RFC 3066 well-formedness was also added.</t><t>Added text to the end of <xref target="recordformat"></xref> noting that future versions of this document might add new field types to the Registry format and recommending that implementations ignore any unrecognized fields.</t><t>Added text about what the lack of a Suppress-Script field means in a record to <xref target="suppressfield"></xref>.</t><t>Added text allowing the correction of misspellings and typographic errors to <xref target="descriptionfield"></xref>.</t><t>Added text to <xref target="prefixfield"></xref> disallowing Prefix field conflicts (such as circular prefix references).</t><t>Modified text in <xref target="registrationProc"></xref> to require the subtag reviewer to announce his/her decision (or extension) following the two-week period. Also clarified that any decision or failure to decide can be appealed.</t><t>Modified text in <xref target="choice"></xref> to include the (heretofore anecdotal) guiding principle of tag choice, and clarifying the non-use of script subtags in non-written applications. Also updated examples in this section to use Chamic languages as an example of language collections.</t><t>Prohibited multiple use of the same variant in a tag (i.e. "de-1901-1901"). Previously this was only a recommendation ("SHOULD").</t><t>Removed inappropriate <xref target="RFC2119"></xref> language from the illustration in <xref target="bufferLimits"></xref>.</t><t>Replaced the example of deprecating "zh-gouyu" with "zh-hakka"-&gt;"hak" in <xref target="canonical"></xref>, noting that it was this document that caused the change.</t><t>Replaced the section in <xref target="choice"></xref> dealing with "mul"/"und" to include the subtags 'zxx' and 'mis', as well as the tag "i-default". A normative reference to RFC 2277 was added, along with an informative reference to MARC21.</t><t>Added text to <xref target="registrationProc"></xref> clarifying that any modifications of a registration request must be sent to the ietf-languages list before submission to IANA.</t><t>Changed the ABNF for the record-jar format from using the LWSP production to use a folding whitespace production similar to obs-FWS in <xref target="RFC5234"></xref>. This effectively prevents unintentional blank lines inside a field. </t><t>Clarified and revised text in <xref target="maintreg"></xref>, <xref target="registrationProc"></xref>, and <xref target="iana-subtag-reg"></xref> to clarify that the Language Subtag Reviewer sends the complete registration forms to IANA, that IANA extracts the record from the form, and that the forms must also be archived separately from the registry.</t><t>Added text to <xref target="iana"></xref> requiring IANA to send an announcement to an ietf-languages-announce list whenever the registry is updated.</t>
 <t>Modification of the registry to use UTF-8 as its character encoding. This also entails additional instructions to IANA and the Language Subtag Reviewer in the registration process.</t><t>Modified the rules in <xref target="region"></xref> so that "exceptionally reserved" ISO 3166-1 codes other than 'UK' were included into the registry. In particular, this allows the code 'EU' (European Union) to be used to form language tags or (more commonly) for applications that use the registry for region codes to reference this subtag.</t><t>Modified the <xref target="iana">IANA considerations section</xref> to remove unnecessary normative <xref target="RFC2119"></xref> language.</t></list>
 </t>
 
@@ -1124,7 +1123,7 @@
   &rfc3339;  

-&rfc4234;<reference anchor="RFC4645" target="http://www.ietf.org/rfc/rfc4645.txt"><front><title abbrev="draft-ietf-ltru-initial-registry">Initial Language Subtag Registry</title><author initials="D" surname="Ewell" fullname="Doug Ewell" role="editor"><organization>LTRU Working Group</organization></author><date day="10" month="September" year="2006"/></front></reference><reference anchor="RFC4647" target="http://www.ietf.org/rfc/rfc4647.txt"><front><title abbrev="draft-ietf-ltru-initial-registry">Matching of Language Tags</title><author initials="A" surname="Phillips" fullname="Addison Phillips" role="editor"><organization>LTRU Working Group</organization></author><author initials="M" surname="Davis" fullname="Mark Davis" role="editor"><organization>LTRU Working Group</organization></author><date day="10" month="September" year="2006"/></front></reference></references>
+&rfc5234;<reference anchor="RFC4645" target="http://www.ietf.org/rfc/rfc4645.txt"><front><title abbrev="draft-ietf-ltru-initial-registry">Initial Language Subtag Registry</title><author initials="D" surname="Ewell" fullname="Doug Ewell" role="editor"><organization>LTRU Working Group</organization></author><date day="10" month="September" year="2006"/></front></reference><reference anchor="RFC4647" target="http://www.ietf.org/rfc/rfc4647.txt"><front><title abbrev="draft-ietf-ltru-initial-registry">Matching of Language Tags</title><author initials="A" surname="Phillips" fullname="Addison Phillips" role="editor"><organization>LTRU Working Group</organization></author><author initials="M" surname="Davis" fullname="Mark Davis" role="editor"><organization>LTRU Working Group</organization></author><date day="10" month="September" year="2006"/></front></reference></references>
 <references title="Informative References">
 <reference anchor="registry-update" target="http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-registry-00.txt"><front><title abbrev="draft-ietf-ltru-initial-registry">Update to the Language Subtag Registry</title><author initials="D" surname="Ewell" fullname="Doug Ewell" role="editor"><organization>LTRU Working Group</organization></author><date day="12" month="September" year="2006"/></front></reference><reference anchor="RFC4646" target="http://www.ietf.org/rfc/rfc4646.txt"><front><title abbrev="draft-ietf-ltru-initial-registry">Tags for the Identification of Languages</title><author initials="A" surname="Phillips" fullname="Addison Phillips" role="editor"><organization>LTRU Working Group</organization></author><author initials="M" surname="Davis" fullname="Mark Davis" role="editor"><organization>LTRU Working Group</organization></author><date day="10" month="September" year="2006"/></front></reference><reference anchor="iso639.prin" target="http://www.loc.gov/standards/iso639-2/iso639jac_n3r.html">
  <front>
_______________________________________________
Ltru mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 20 Feb 2008 10:29:35 -0800

Hi -

> From: "Stephane Bortzmeyer" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Wednesday, February 20, 2008 2:22 AM
> Subject: [Ltru] Implementation report (Was: Begin LTRU WG last call on4646bis and 4645bis
...

Thank you for the implementation report.
It's very helpful to know that someone has successfully
built an implementation using the specification.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 20 Feb 2008 10:35:17 -0800

Hi -

> Sent: Wednesday, February 20, 2008 2:41 AM
> Subject: Re: [Ltru] Some typos (Was: Begin LTRU WG last call on 4646bis and4645bis
>
...

The xml diff isn't particularly clear - particularly since this patch appears
to implement a bit more than your earlier comments.  It's usually
better for discussion to have the resulting diffs to the i-d text.

Randy

---

From: Addison Phillips <[email-masked]>
Date: Wed, 20 Feb 2008 11:02:31 -0800

All,

I did an edit to remove extraneous references to 'extlangs'. I also 
implemented a change like that suggested by Stephane below, except that 
I incorporated a reference using a redundant tag from the 4646 era.

I am just starting to catch up on the emails over the past week. In 
addition to my day job (just a few distractions there), I'm also caring 
for a terminally ill relative. So I'm just a bit behind :-).

NOTE WELL: this editor is exceedingly unhappy to receive large diff 
markups labeled as "editorial". I will look through the ones already 
submitted, but it is not helpful to send more of the same to me if you 
can describe the specific problem. Please follow the protocol for 
comments from the chairs to ensure that I can track individual issues 
and check them off as they become consensual. The files on inter-locale 
are presently up to date, including the changes noted above in the 
editor's copies. They are linked off of the home page or you can find 
them at:

  http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-12.txt
  http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-12.xml
  http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-12.html

Addison

Stephane Bortzmeyer wrote:
> ------------------------------------------------------------------------
>

---

From: Addison Phillips <[email-masked]>
Date: Wed, 20 Feb 2008 11:23:51 -0800

> built an implementation using the specification.

Interestingly, I'm also in the process of creating a new version of Java 
code. So far it is smooth sailing. When I'm done and JUnit runs clean, 
I'll see if Yahoo! will let me post it visibly. Of interest to this 
group might be this snippet of well-formed checking as Java regex 
(Stephane, you're welcome to reproduce on langtag.net):

         String regex =
             "([xX]([\\x2d]\\p{Alnum}{1,8})*)|((\\p{Alpha}{2,8})"
             + "([\\x2d](\\p{Alpha}{4}))?"
             + "([\\x2d](\\p{Alpha}{2}|\\d{3}))?"
             + "([\\x2d]((\\d\\p{Alnum}{3})|(\\p{Alnum}{5,8})))*"
             + "(([\\x2d]([a-wyzA-WYZ])([\\x2d](\\p{Alnum}{2,8})+)*))*"
             + "([\\x2d][xX]([\\x2d]\\p{Alnum}{1,8})*)?)";

Addison

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 20 Feb 2008 21:52:50 +0100

On Wed, Feb 20, 2008 at 10:35:17AM -0800,
 Randy Presuhn <[email-masked]> wrote 
 a message of 34 lines which said:

> to implement a bit more than your earlier comments. 

As I said in my message
(http://www.ietf.org/mail-archive/web/ltru/current/msg09544.html),
just my earlier comments MINUS the removal of the term "primary
language" PLUS the forgotten "irregular" grandfathered tags.

> It's usually better for discussion to have the resulting diffs to
> the i-d text.

Well, I thought it would be easier for the editor (using a XML-aware
diff would have been even better), but I will follow the protocol.

---

From: Addison Phillips <[email-masked]>
Date: Wed, 20 Feb 2008 13:05:41 -0800

I've got those in, mostly, except for "irregular", which is the next 
little task on my list.

Addison

---

From: Addison Phillips <[email-masked]>
Date: Thu, 21 Feb 2008 11:01:16 -0800

Editor hat on except as noted. Changes to be posted to editor's copy in 
a couple of minutes.
>     subtags MUST include exactly one 'Prefix' field".)

DONE. All instances of extlang removed. Some editorial work on the 
extlang section was completed and references to them handled as appropriate.

> retaining the 'primary' because one could think of a language tag as 
> being composed of a sequence of "language subtags". We don't, but 
> someone could. So it might be worth retaining the 'primary' for clarity.

<as technical contributor>Primary is inherited from RFC 1766 days.</as 
technical contributor>

NO CHANGE.

>     a discussion of the consequences of this decision on the grammar."

DONE.

>     * New Macrolanguage field (see 3.1.9)

DONE.
>     5234 (no consequences for us since we do not use LWSP)

DONE.