From ltru-bounces@ietf.org Sat Sep 02 10:40:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJWeu-00031l-S1; Sat, 02 Sep 2006 10:39:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJWet-00031g-Oa for ltru@lists.ietf.org; Sat, 02 Sep 2006 10:39:43 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJWeo-0007r4-Ek for ltru@lists.ietf.org; Sat, 02 Sep 2006 10:39:43 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GJWei-0004Vn-D0 for ltru@lists.ietf.org; Sat, 02 Sep 2006 16:39:32 +0200 Received: from du-001-033.access.de.clara.net ([212.82.227.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Sep 2006 16:39:32 +0200 Received: from nobody by du-001-033.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Sep 2006 16:39:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 02 Sep 2006 16:38:18 +0200 Organization: Lines: 31 Message-ID: <44F99759.10EE@xyzzy.claranet.de> References: <20060829192613.87DB625970D@eikenes.alvestrand.no> <006101c6ce60$1fc82330$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-033.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Ltru] variant Suppress-Script (was: Request for variant subtags "scouse" and "boont") X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote on the other list: > I wonder, however, if we (LTRU) might have a need in the > future to revise those rules and allow a Suppress-Script > for a language-variant combination. I don't have a real > example, but close your eyes and pretend for a moment that > we are faced with a dialect of Mongolian that warrants a > variant on proper linguistic grounds, and coincidentally > happens to be written overwhelmingly in Cyrillic script > and virtually never in Mongolian script. In that hypothetical > case, it might be appropriate to consider that the > language-variant combination "mn-whatever" should have a > Suppress-Script of "Cyrl" even though "mn" by itself has > none. Just a thought. It's certainly an interesting fact. IMO Suppress-Script is a kludge for naive applications, and situations like right to left truncation or left to right matching. They'd end up with "I can see an mn and whatever and no script, and there is no Suppress-Script for mn" (for new 3066bis applications). To confuse "old" 3066-applications (= all existing browsers and Web servers) add a region code as in mn-RU-whatever vs. mn-Cyrl-RU-whatever. At the moment we have four cases: both sides new, both old, old client + new server, or vice versa. With a new Suppress-Script rule we'd get nine cases. I can't tell immediately if that could fail miserably in some cases. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 03 15:42:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJxr8-0003Mv-W3; Sun, 03 Sep 2006 15:42:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJxr8-0003Mm-2h for ltru@ietf.org; Sun, 03 Sep 2006 15:42:10 -0400 Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime03.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJxim-0006oj-U7 for ltru@ietf.org; Sun, 03 Sep 2006 15:33:34 -0400 Received: from eupig2 (unverified [129.1.30.40]) by lonsmime03.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Sun, 3 Sep 2006 19:33:25 +0000 Received: from lonsmsxb01.emea.ime.reuters.com ([10.14.113.6]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31217) with ESMTP id <0J5100KJK7NPM7@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Sun, 03 Sep 2006 19:33:25 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Sun, 03 Sep 2006 20:33:25 +0100 Date: Sun, 03 Sep 2006 20:33:23 +0100 From: Misha Wolf To: ltru@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: Generic variants and Armenian dialects Thread-Index: AcbPiQsjtdPn1ziIRAOpoOeNLti1JwABqeFg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 03 Sep 2006 19:33:25.0258 (UTC) FILETIME=[D2EBCEA0:01C6CF8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Ltru] FW: Generic variants and Armenian dialects X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org For the LTRU to consider ... Misha -----Original Message----- From: Doug Ewell [mailto:dewell@adelphia.net]=20 Sent: 03 September 2006 19:43 To: ietf-languages@iana.org Cc: Misha Wolf Subject: Re: Generic variants and Armenian dialects Misha Wolf wrote: > The only bit of your message that worries me is the discussion of=20 > "en-1901". Yes, I know you were commenting on a mail of John's. > > It's one thing to argue that we should use the Armenian word for East=20 > or West to ensure the variants are not used in an arbitrary manner=20 > elsewhere. It's quite another to assign a year number to one language > only. What if two languages underwent spelling reform in 2007? Would > one of them not be allowed to use "2007"? This seems wrong to me. Given that we have implemented "spelling reform" variant subtags for=20 only one language, and the practical need for those has been called into question, this scenario seems quite remote. Still, anything is=20 possible. There is a special production in the ABNF to allow a 4-character variant that begins with a digit. The obvious intent of this is to indicate the year in which some change was made in the language that is significant=20 enough to justify a variant (such as a spelling reform). Perhaps LTRU=20 should consider defining a distinction between this type of "date"=20 variant, which could in theory apply to more than one language (even=20 though the reforms themselves would be different), and the "usual" type=20 such as Resianic or Boontling or Scouse or Eastern [Armenian], which in=20 theory could not ("Eastern Quinqui" would not have the same relative=20 meaning as "Eastern Armenian," except geographically). -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ Editor, draft-ietf-ltru-initial To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 03 16:08:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJyGn-0003lc-Fq; Sun, 03 Sep 2006 16:08:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJyGm-0003lV-FX for ltru@ietf.org; Sun, 03 Sep 2006 16:08:40 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJyGl-0004ia-8E for ltru@ietf.org; Sun, 03 Sep 2006 16:08:40 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060903200836.QQCF2942.mta9.adelphia.net@DGBP7M81> for ; Sun, 3 Sep 2006 16:08:36 -0400 Message-ID: <014901c6cf94$b94e1750$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 3 Sep 2006 13:08:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Ltru] Re: Test suite for language tags? (Frank Ellermann) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> additions are of course very welcome > > For well-formed: > > abcd-Latn > AaBbCcDd-x-y-any-x > > For broken: > > abcd-efg > aabbccddE Thanks for bringing up the abcd-efg case. I'd forgotten that extlangs can only follow a 2- or 3-letter primary language subtag, not only semantically (because of their genesis) but also syntactically: language = (2*3ALPHA [ extlang ]) ; shortest ISO 639 code / 4ALPHA ; reserved for future use / 5*8ALPHA ; registered language subtag extlang = *3("-" 3ALPHA) ; reserved for future use -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ Editor, draft-ietf-ltru-initial _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 04 11:22:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKGH8-0005Q4-Qb; Mon, 04 Sep 2006 11:22:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKGH7-0005Ov-5N for ltru@ietf.org; Mon, 04 Sep 2006 11:22:13 -0400 Received: from mail1.microsoft.com ([131.107.1.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKGH1-0003Gc-RT for ltru@ietf.org; Mon, 04 Sep 2006 11:22:13 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Sep 2006 08:22:07 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.156]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Sep 2006 08:22:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6D035.BFF1EF98" Date: Mon, 4 Sep 2006 08:21:07 -0700 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: prefixes for date variants (was Re: Generic variants and Armenian dialects) Thread-Index: AcbPiN6/RJAaQz3RS/2KAc9IB1E7VgAnCwlQAAQmKaA= From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 04 Sep 2006 15:22:06.0823 (UTC) FILETIME=[E1E2F770:01C6D035] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Ltru] prefixes for date variants (was Re: Generic variants and Armenian dialects) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D035.BFF1EF98 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KG1vdmluZyB0byBMVFJVKQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWV0 Zi1sYW5ndWFnZXMtYm91bmNlc0BhbHZlc3RyYW5kLm5vIFttYWlsdG86aWV0Zi1sYW5ndWFnZXMt Ym91bmNlc0BhbHZlc3RyYW5kLm5vXSBPbiBCZWhhbGYgT2YgUGV0ZXIgQ29uc3RhYmxlDQpTZW50 OiBNb25kYXksIFNlcHRlbWJlciAwNCwgMjAwNiA3OjExIEFNDQpUbzogaWV0Zi1sYW5ndWFnZXNA aWFuYS5vcmcNClN1YmplY3Q6IFJFOiBHZW5lcmljIHZhcmlhbnRzIGFuZCBBcm1lbmlhbiBkaWFs ZWN0cw0KDQo+IEZyb206IGlldGYtbGFuZ3VhZ2VzLWJvdW5jZXNAYWx2ZXN0cmFuZC5ubyBbbWFp bHRvOmlldGYtbGFuZ3VhZ2VzLQ0KPiBib3VuY2VzQGFsdmVzdHJhbmQubm9dIE9uIEJlaGFsZiBP ZiBEb3VnIEV3ZWxsDQoNCg0KPiA+IFRoZSBvbmx5IGJpdCBvZiB5b3VyIG1lc3NhZ2UgdGhhdCB3 b3JyaWVzIG1lIGlzIHRoZSBkaXNjdXNzaW9uIG9mDQo+ID4gImVuLTE5MDEiLi4uDQoNCg0KPiBQ ZXJoYXBzIExUUlUNCj4gc2hvdWxkIGNvbnNpZGVyIGRlZmluaW5nIGEgZGlzdGluY3Rpb24gYmV0 d2VlbiB0aGlzIHR5cGUgb2YgImRhdGUiDQo+IHZhcmlhbnQsIHdoaWNoIGNvdWxkIGluIHRoZW9y eSBhcHBseSB0byBtb3JlIHRoYW4gb25lIGxhbmd1YWdlIChldmVuDQo+IHRob3VnaCB0aGUgcmVm b3JtcyB0aGVtc2VsdmVzIHdvdWxkIGJlIGRpZmZlcmVudCksIGFuZCB0aGUgInVzdWFsIiB0eXBl DQo+IHN1Y2ggYXMgUmVzaWFuaWMgb3IgQm9vbnRsaW5nIG9yIFNjb3VzZSBvciBFYXN0ZXJuIFtB cm1lbmlhbl0sIHdoaWNoIGluDQo+IHRoZW9yeSBjb3VsZCBub3QgKCJFYXN0ZXJuIFF1aW5xdWki IHdvdWxkIG5vdCBoYXZlIHRoZSBzYW1lIHJlbGF0aXZlDQo+IG1lYW5pbmcgYXMgIkVhc3Rlcm4g QXJtZW5pYW4sIiBleGNlcHQgZ2VvZ3JhcGhpY2FsbHkpLg0KDQpUaGUgcG9ydGlvbiB5b3UgcXVv dGVkIGRvZXNuJ3QgYXBwZWFyIHRvIHByZXZlbnQgdXMgZnJvbSBzcGVjaWZ5aW5nIG11bHRpcGxl IHByZWZpeGVzIGZvciBhIGRhdGUgdmFyaWFudDsgaXQgbWVyZWx5IHN1Z2dlc3RzICh3cm9uZ2x5 LCBJIHRoaW5rIHdlIGNhbiBhZ3JlZSkgdGhhdCBhIG5ldyBwcmVmaXggZm9yIGUuZy4gMTk5NiB1 bnJlbGF0ZWQgdG8gREUgd291bGQgcHJvYmFibHkgYmUgcmVqZWN0ZWQuIFdlIGNvdWxkIHJldmlz ZSB0byBtYWtlIGNsZWFyIHRoYXQgd2UgYWxsb3cgZGF0ZXMgdG8gYmUgdXNlZCB3aXRoIHVucmVs YXRlZCBwcmVmaXhlcyAtLSBwcm9iYWJseSBhIHNpbXBsZSBjaGFuZ2Ugd291bGQgZG86DQoNCiJS ZXF1ZXN0cyB0byBhZGQgYSBwcmVmaXggdG8gYSBub24tZGF0ZSB2YXJpYW50IHN1YnRhZyB0aGF0 IGltcGx5IGEgZGlmZmVyZW50IHNlbWFudGljIG1lYW5pbmcgd2lsbCBwcm9iYWJseSBiZSByZWpl Y3RlZC4gKFRoaXMgd291bGQgYmUgcGVybWl0dGVkIHdoZW4gYXBwcm9wcmlhdGUgZm9yIGZvdXIt ZGlnaXQgdmFyaWFudCBzdWJ0YWdzIHJlcHJlc2VudGluZyBkYXRlcy4pIC4uLiAiDQoNCg0KDQpQ ZXRlciBDb25zdGFibGUNCg== ------_=_NextPart_001_01C6D035.BFF1EF98 Content-Type: text/plain; name="ATT9095079.txt" Content-Transfer-Encoding: base64 Content-Description: ATT9095079.txt Content-Disposition: attachment; filename="ATT9095079.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklldGYtbGFu Z3VhZ2VzIG1haWxpbmcgbGlzdA0KSWV0Zi1sYW5ndWFnZXNAYWx2ZXN0cmFuZC5ubw0KaHR0cDov L3d3dy5hbHZlc3RyYW5kLm5vL21haWxtYW4vbGlzdGluZm8vaWV0Zi1sYW5ndWFnZXMNCg== ------_=_NextPart_001_01C6D035.BFF1EF98 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------_=_NextPart_001_01C6D035.BFF1EF98-- From ltru-bounces@ietf.org Mon Sep 04 13:50:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKIaY-0006Ii-Jq; Mon, 04 Sep 2006 13:50:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKIaX-0006Ic-HY for ltru@ietf.org; Mon, 04 Sep 2006 13:50:25 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKIaW-00028V-9u for ltru@ietf.org; Mon, 04 Sep 2006 13:50:25 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060904175023.ZWE2942.mta9.adelphia.net@DGBP7M81> for ; Mon, 4 Sep 2006 13:50:23 -0400 Message-ID: <001a01c6d04a$934c8260$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 4 Sep 2006 10:50:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ltru] Re: prefixes for date variants (was Re: Generic variants and Armenian dialects X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > The portion you quoted doesn't appear to prevent us from specifying > multiple prefixes for a date variant; it merely suggests (wrongly, I > think we can agree) that a new prefix for e.g. 1996 unrelated to DE > would probably be rejected. We could revise to make clear that we > allow dates to be used with unrelated prefixes -- probably a simple > change would do: > > "Requests to add a prefix to a non-date variant subtag that imply a > different semantic meaning will probably be rejected. (This would be > permitted when appropriate for four-digit variant subtags representing > dates.) ... " That's pretty much what I had in mind. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 05 14:05:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKfIA-0002hO-W8; Tue, 05 Sep 2006 14:04:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKfI9-0002hE-W9 for ltru@ietf.org; Tue, 05 Sep 2006 14:04:57 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKfI8-0008Ct-KO for ltru@ietf.org; Tue, 05 Sep 2006 14:04:57 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k85I4kbY063021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Sep 2006 11:04:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=dMfR+ID3+tMQZwUlJp0oURUxAg8ujWoM/EzOp15ALhLg6VyEkAxYijrmpZpURkTG Message-ID: <44FDBC3E.3010702@yahoo-inc.com> Date: Tue, 05 Sep 2006 11:04:46 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] prefixes for date variants (was Re: Generic variants and Armenian dialects) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > >> Perhaps LTRU >> should consider defining a distinction between this type of "date" >> variant, which could in theory apply to more than one language (even >> though the reforms themselves would be different), and the "usual" type >> such as Resianic or Boontling or Scouse or Eastern [Armenian], which in >> theory could not ("Eastern Quinqui" would not have the same relative >> meaning as "Eastern Armenian," except geographically). > > The portion you quoted doesn't appear to prevent us from specifying > multiple prefixes for a date variant; it merely suggests (wrongly, > I think we can agree) that a new prefix for e.g. 1996 unrelated > to DE would probably be rejected. We could revise to make clear > that we allow dates to be used with unrelated prefixes -- > probably a simple change would do: > > "Requests to add a prefix to a non-date variant subtag that > imply a different semantic meaning will probably be > rejected. (This would be permitted when appropriate for > four-digit variant subtags representing dates.) ... " -1 "Date variants" are not defined anywhere and I don't believe we should get into the business of defining them. We need to deal with the problem of adding a prefix to a variant. I think the correct response to our problems here, as Mark pointed out, is to REMOVE the validation requirement of checking the variant prefix. Checking the prefix fundamentally means that no prefix can be added to a variant in the future (since existing validating tag processors will reject the new tags). That is bad. This change would reduce variant prefixes to their intended behavior (which is informative). "Date" variants, like any other semi-generic variant, can therefore acquire new prefixes. I think there are shades of "redefining meaning" that are being advised against above (and note that the text says that the redefinition will "probably" be rejected, not a guarantee or requirement that it be rejected). "nedis" is a case where another prefix can never be warranted: no other language is going to have a Nadiza dialect. "1901" is a case where another language *could* have an "orthography of 1901". "western" is a case where another language *could* have a "Western dialect". But these don't change the "meaning" of the subtags--the meaning of the tag they appear in is different, though. This is not new. Consider the tags "nl-BE" and "fr-BE". The subtag 'BE' means the same thing in both: the country of Belgium. But the dialects defined by either is fundamentally different (the Belgian dialect of Dutch is not the same thing as nor does it bear the quite same relationship to the parent language as does the Belgian dialect of French). Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 06 10:18:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKyEK-00024t-HR; Wed, 06 Sep 2006 10:18:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKyEJ-00024o-Ju for ltru@ietf.org; Wed, 06 Sep 2006 10:18:15 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKyEF-0002WZ-Df for ltru@ietf.org; Wed, 06 Sep 2006 10:18:15 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GKyE8-0001NF-Co; Wed, 06 Sep 2006 10:18:04 -0400 Date: Wed, 6 Sep 2006 10:18:04 -0400 To: Addison Phillips Subject: Re: [Ltru] prefixes for date variants (was Re: Generic variants and Armenian dialects) Message-ID: <20060906141804.GC30236@ccil.org> References: <44FDBC3E.3010702@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44FDBC3E.3010702@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > I think the correct response to our problems here, as Mark pointed out, > is to REMOVE the validation requirement of checking the variant prefix. +1 -- No, John. I want formats that are actually John Cowan useful, rather than over-featured megaliths that http://www.ccil.org/~cowan address all questions by piling on ridiculous cowan@ccil.org internal links in forms which are hideously over-complex. --Simon St. Laurent on xml-dev _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 06 12:44:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL0Vv-0004y2-Jc; Wed, 06 Sep 2006 12:44:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL0Vu-0004xs-J6 for ltru@ietf.org; Wed, 06 Sep 2006 12:44:34 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL0Vt-0000HV-96 for ltru@ietf.org; Wed, 06 Sep 2006 12:44:34 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 628261E13B8; Wed, 6 Sep 2006 09:44:30 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Wed, 6 Sep 2006 09:44:30 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EEEB@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'John Cowan' , Addison Phillips Subject: RE: [Ltru] prefixes for date variants (was Re: Generic variants a nd Armenian dialects) Date: Wed, 6 Sep 2006 09:44:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: Wednesday, September 06, 2006 10:18 AM > To: Addison Phillips > Cc: LTRU Working Group > Subject: Re: [Ltru] prefixes for date variants (was Re: > Generic variants > and Armenian dialects) > > > Addison Phillips scripsit: > > > I think the correct response to our problems here, as Mark > pointed out, > > is to REMOVE the validation requirement of checking the > variant prefix. > > +1 > > -- > No, John. I want formats that are actually John Cowan > useful, rather than over-featured megaliths that > http://www.ccil.org/~cowan > address all questions by piling on ridiculous cowan@ccil.org > internal links in forms which are hideously > over-complex. --Simon St. Laurent on xml-dev > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.11.7/437 - Release Date: 9/4/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 06 15:50:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3Pk-000680-Pe; Wed, 06 Sep 2006 15:50:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3PP-0005q1-G2; Wed, 06 Sep 2006 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL3PP-0001Lq-6h; Wed, 06 Sep 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 061D626E49; Wed, 6 Sep 2006 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GL3PO-00029i-OO; Wed, 06 Sep 2006 15:50:02 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Wed, 06 Sep 2006 15:50:02 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ltru@ietf.org Subject: [Ltru] WG Action: RECHARTER: Language Tag Registry Update (ltru) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org The Language Tag Registry Update (ltru) working group in the Applications Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. +++ Language Tag Registry Update (ltru) =================================== Current Status: Active Working Group Chair(s): Randy Presuhn Martin Duerst Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Ted Hardie Mailing Lists: General Discussion: ltru@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ltru Archive: http://www.ietf.org/mail-archive/web/ltru/index.html Description of Working Group: The primary language subtags allowed by the current IANA Language Subtag Registry are limited to ISO 639-1 and ISO 639-2 in the same way as they were limited by RFC 3066. This covers approximately 500 possible language subtags. ISO 639-3, scheduled for approval towards the end of 2006, will make available around 7000 more code elements for identifying languages. The working group will prepare an update to the Language Subtag Registry procedures to allow the use of 3-letter code elements from ISO 639-3 as primary language subtags or extended language subtags as appropriate. The working group will also deliver means to update the current IANA Language Subtag Registry with the newly available subtags. The working group will examine, and if necessary clarify or adjust, procedures and guidelines with respect to extended language subtags and variant subtags. Use cases include the identification of signed languages, transliterations, and transcriptions. The working group will also consider how the draft work on ISO 639-6 may relate to the future development of language tags. The working group will clarify text where necessary. It may also make adjustments to the registration process and the form of the registry if this is deemed appropriate based on ongoing registration and operational experience. These adjustments and clarifications are not expected to delay the progress of the work. Work on the drafts is planned to start before ISO 639-3 is fully approved and published. However, the WG will not finalize the drafts before ISO 639-3 is fully approved. Goals and Milestones: September 2006 Submit first WG draft of registry procedure update September 2006 Submit first WG draft of registry data update January 2007 Submit registry procedure update draft for IETF Last Call January 2007 Submit registry data update draft for IETF Last Call _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 06 22:22:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL9WZ-0002OB-Vk; Wed, 06 Sep 2006 22:21:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL202-0006vE-DP for ltru@ietf.org; Wed, 06 Sep 2006 14:19:46 -0400 Received: from pne-smtpout1-sn2.hy.skanova.net ([81.228.8.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL201-0004PN-4L for ltru@ietf.org; Wed, 06 Sep 2006 14:19:46 -0400 Received: from chalmers95a69n (83.248.26.72) by pne-smtpout1-sn2.hy.skanova.net (7.2.075) id 44FECFC6000134D8 for ltru@ietf.org; Wed, 6 Sep 2006 20:19:37 +0200 From: "Kent Karlsson" To: "'LTRU Working Group'" Subject: RE: [Ltru] prefixes for date variants (was Re: Generic variants andArmenian dialects) Date: Wed, 6 Sep 2006 20:19:14 +0200 Message-ID: <005701c6d1e0$f939c4b0$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20060906141804.GC30236@ccil.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Wed, 06 Sep 2006 22:21:50 -0400 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > Addison Phillips scripsit: > > > I think the correct response to our problems here, as Mark > pointed out, > > is to REMOVE the validation requirement of checking the > variant prefix. I don't understand. ANY new subtag will be "flagged" by a validating language tag processor that has not been updated to include the new subtag. The same would go for newly registered prefix(es) for already existing variant subtag(s) and a validating language tag processor that has not been updated to include the new prefix(es). If the "validation requirement of checking the variant prefix" is removed, why not remove also the "validation requirement of checking the subtag registration". (Which would make validation rather pointless, since there would be no validation...) I may have missed something, but did anyone (e.g. Mark) actually suggest removing the prefix validation (for validating language tag processors)? /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 06 23:44:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLAoF-0007v3-5Y; Wed, 06 Sep 2006 23:44:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLAoD-0007u5-Dj for ltru@ietf.org; Wed, 06 Sep 2006 23:44:09 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLAlH-0005s0-92 for ltru@ietf.org; Wed, 06 Sep 2006 23:41:10 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.628.4; Wed, 6 Sep 2006 20:41:06 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Wed, 6 Sep 2006 20:41:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] prefixes for date variants (was Re: Generic variantsandArmenian dialects) Date: Wed, 6 Sep 2006 20:40:25 -0700 Message-ID: In-Reply-To: <005701c6d1e0$f939c4b0$6500a8c0@chalmers95a69n> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] prefixes for date variants (was Re: Generic variantsandArmenian dialects) thread-index: AcbSJHoKWHo+6A87RfeyX6nrr0OXlgACsQqA From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 07 Sep 2006 03:41:05.0030 (UTC) FILETIME=[7257F260:01C6D22F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Kent Karlsson [mailto:kent.karlsson14@comhem.se] > > > I think the correct response to our problems here, as Mark > > pointed out, > > > is to REMOVE the validation requirement of checking the > > variant prefix. >=20 > I don't understand. >=20 > ANY new subtag will be "flagged" by a validating language tag processor > that has not been updated to include the new subtag. I was thinking the same thing. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 07 00:10:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLBDT-0001uk-Pa; Thu, 07 Sep 2006 00:10:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLBDS-0001ub-L6 for ltru@ietf.org; Thu, 07 Sep 2006 00:10:14 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLBDR-00063w-AB for ltru@ietf.org; Thu, 07 Sep 2006 00:10:14 -0400 Received: from [10.72.72.23] (snvvpn1-10-72-72-c23.corp.yahoo.com [10.72.72.23]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k874A0QE038736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Sep 2006 21:10:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=HCyRIGNuX36U1G4yhIp2K/jwSP/5m3X0SgRu5DBY1lzv2JbvEIsxnxlSPO61B1jk Message-ID: <44FF9B97.60304@yahoo-inc.com> Date: Wed, 06 Sep 2006 21:09:59 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] prefixes for date variants (was Re: Generic variantsandArmenian dialects) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: >> From: Kent Karlsson [mailto:kent.karlsson14@comhem.se] > > >>>> I think the correct response to our problems here, as Mark >>> pointed out, >>>> is to REMOVE the validation requirement of checking the >>> variant prefix. >> I don't understand. >> >> ANY new subtag will be "flagged" by a validating language tag > processor >> that has not been updated to include the new subtag. > > I was thinking the same thing. > For entirely unknown subtags, yes. But... with validation currently requiring prefix checking, adding a prefix causes existing parsers to reject known subtags. Rejecting an unknown subtag is one thing. Rejecting an unknown prefix for a known subtag is something else. If we want to support generic variant subtags, the prefix is *informative* information about what that subtag means in a given context. So rejecting a subtag for using an unknown prefix is undesirable behavior, from a stability point of view. The alternative is that the prefixes are normative and two validating parsers with different dates will produce different results. That is, the parser pre-new-prefix rejects tags validated by a parser post-new-prefix. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 07 02:29:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLDOH-00016S-OC; Thu, 07 Sep 2006 02:29:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLDOG-00016C-5I for ltru@ietf.org; Thu, 07 Sep 2006 02:29:32 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLDOE-0006nx-SK for ltru@ietf.org; Thu, 07 Sep 2006 02:29:32 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060907062930.JGWR29000.mta13.adelphia.net@DGBP7M81> for ; Thu, 7 Sep 2006 02:29:30 -0400 Message-ID: <013c01c6d246$f8763d40$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] prefixes for date variants Date: Wed, 6 Sep 2006 23:29:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I think the correct response to our problems here, as Mark pointed > out, is to REMOVE the validation requirement of checking the variant > prefix. Checking the prefix fundamentally means that no prefix can be > added to a variant in the future (since existing validating tag > processors will reject the new tags). That is bad. This change would > reduce variant prefixes to their intended behavior (which is > informative). Existing tag processors will reject the new tags only if they are utilizing an outdated copy of the Registry. Such a processor would also reject the now-valid tag "zza" if its copy of the Registry is older than 2006-08-29. The same situation applies to variant prefixes. We could remove the validation requirement in Section 2.2.9 and still leave the passages in Sections 2.2.5 and 3.1, which use words like "suitable" and "appropriate." This would put the use of variants with non-recommended prefixes into the same moral category as deprecated subtags and explicitly specified Suppress-Scripts, which feels like the Right Thing. > "Date" variants, like any other semi-generic variant, can therefore > acquire new prefixes. I think there are shades of "redefining meaning" > that are being advised against above (and note that the text says that > the redefinition will "probably" be rejected, not a guarantee or > requirement that it be rejected). I believe the use case we had in mind at the time was indeed something like "western", and the premise was that it would be virtually assured of rejection. I could try looking this up in the archives. At the very least, I think we should not go searching for variants that can be reused. If a scenario for reuse should materialize, like the Great Zaza Spelling Reform of 1996, then so be it. But I for one am glad that the Armenian variants have been changed to apply narrowly to Armenian. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ Editor, draft-ietf-ltru-initial _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 07 12:05:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLMNN-0004LY-Ez; Thu, 07 Sep 2006 12:05:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLMNM-0004KP-4v for ltru@ietf.org; Thu, 07 Sep 2006 12:05:12 -0400 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLMNI-0004D8-Op for ltru@ietf.org; Thu, 07 Sep 2006 12:05:12 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Yp3GsAtM3DdDO+bgTwFrbEtoOhs3IEUJZ6vY7rXlkMkwQEQmIfCIEQAqK46x6dKt; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.6.41] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GLMNI-0003CT-EB for ltru@ietf.org; Thu, 07 Sep 2006 12:05:08 -0400 Message-ID: <001501c6d297$cdf7c6a0$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <013c01c6d246$f8763d40$6401a8c0@DGBP7M81> Subject: Re: [Ltru] prefixes for date variants Date: Thu, 7 Sep 2006 09:07:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7af03790b7aa0f1db287c5e91dc67fd8b3c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.6.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Wednesday, September 06, 2006 11:29 PM > Subject: Re: [Ltru] prefixes for date variants ... > Existing tag processors will reject the new tags only if they are > utilizing an outdated copy of the Registry. Such a processor would also > reject the now-valid tag "zza" if its copy of the Registry is older than > 2006-08-29. The same situation applies to variant prefixes. ... A reminder - the registry draft says: Although the specification of valid subtags for an extension (see: Section 3.7) MUST be available over the Internet, implementations SHOULD NOT mechanically depend on it being always accessible, to prevent denial-of-service attacks. Consequently, as a technical contributor I think "utilizing an outdated copy" should be considered an extremely likely scenario. Furthermore, it may be worth thinking about when (if ever) a validating processor is really needed. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 07 12:11:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLMTc-0005zL-4J; Thu, 07 Sep 2006 12:11:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLMTa-0005zG-Ve for ltru@ietf.org; Thu, 07 Sep 2006 12:11:38 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLMTZ-000714-Po for ltru@ietf.org; Thu, 07 Sep 2006 12:11:38 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GLMTW-0002es-Is; Thu, 07 Sep 2006 12:11:34 -0400 Date: Thu, 7 Sep 2006 12:11:34 -0400 To: Randy Presuhn Subject: Re: [Ltru] prefixes for date variants Message-ID: <20060907161134.GM14450@ccil.org> References: <013c01c6d246$f8763d40$6401a8c0@DGBP7M81> <001501c6d297$cdf7c6a0$6501a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001501c6d297$cdf7c6a0$6501a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > Consequently, as a technical contributor I think "utilizing an outdated > copy" should be considered an extremely likely scenario. Furthermore, > it may be worth thinking about when (if ever) a validating processor > is really needed. A validating parser will be useful in validating a process's output (be conservative in what you send) rather than its input (be liberal in what you accept). -- There are three kinds of people in the world: John Cowan those who can count, cowan@ccil.org and those who can't. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 07 12:18:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLMa2-0002vF-2e; Thu, 07 Sep 2006 12:18:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLMa0-0002v9-Rr for ltru@ietf.org; Thu, 07 Sep 2006 12:18:16 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLMZz-0000Nt-Id for ltru@ietf.org; Thu, 07 Sep 2006 12:18:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 1AFB726C17C; Thu, 7 Sep 2006 18:18:15 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 46D7826C173; Thu, 7 Sep 2006 18:18:14 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 37E8F58EBBE; Thu, 7 Sep 2006 18:18:14 +0200 (CEST) Date: Thu, 7 Sep 2006 18:18:14 +0200 From: Stephane Bortzmeyer To: John Cowan Message-ID: <20060907161814.GA24475@nic.fr> References: <013c01c6d246$f8763d40$6401a8c0@DGBP7M81> <001501c6d297$cdf7c6a0$6501a8c0@oemcomputer> <20060907161134.GM14450@ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060907161134.GM14450@ccil.org> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: LTRU Working Group Subject: [Ltru] Do we need validating parsers for input? (Was: prefixes for date variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Thu, Sep 07, 2006 at 12:11:34PM -0400, John Cowan wrote a message of 20 lines which said: > A validating parser will be useful in validating a process's output > (be conservative in what you send) rather than its input (be liberal > in what you accept). Since I plan to start a validating parser soon (tm), I'm puzzled. What does "being liberal" means when processing input language tags? Imagine that a process receives uk-Latb-UA. It is well-formed but not valid (typo in the script). I presumed that the sender of this tag would prefer to receive a message "Invalid language tag (subtag Latb is not registered)" rather than "No document found". Don't you agree? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 07 12:28:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLMjq-0007Sf-4r; Thu, 07 Sep 2006 12:28:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLMjp-0007Px-4B for ltru@ietf.org; Thu, 07 Sep 2006 12:28:25 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLMjl-0003Oi-RR for ltru@ietf.org; Thu, 07 Sep 2006 12:28:25 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.628.4; Thu, 7 Sep 2006 09:28:19 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 09:28:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] prefixes for date variants (was Re: Generic variantsandArmenian dialects) Date: Thu, 7 Sep 2006 09:27:51 -0700 Message-ID: In-Reply-To: <44FF9B97.60304@yahoo-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] prefixes for date variants (was Re: Generic variantsandArmenian dialects) thread-index: AcbSM4j3yAYkiHY9T5C6SJn6vuksmQAZgx5g From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 07 Sep 2006 16:28:18.0810 (UTC) FILETIME=[A09D55A0:01C6D29A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Addison Phillips [mailto:addison@yahoo-inc.com] > >> ANY new subtag will be "flagged" by a validating language tag > > processor > >> that has not been updated to include the new subtag. > > > > I was thinking the same thing. > > >=20 > For entirely unknown subtags, yes. But... with validation currently > requiring prefix checking, adding a prefix causes existing parsers to > reject known subtags. But it seems to me we're talking about *tag* validation, not *subtag* validation, yet your response pertains to subtag validation. If that was the issue, then all that matters is whether the subtag is known. But because we're talking about tag validation, while the subtag may be known the particular usage -- the entire tag -- is not. And rejection in that case is no different than rejecting usage of a tag due to an unknown subtag. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 07 12:34:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLMpn-0002cT-9V; Thu, 07 Sep 2006 12:34:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLMpl-0002al-Oh for ltru@ietf.org; Thu, 07 Sep 2006 12:34:33 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLMpj-0004xt-F4 for ltru@ietf.org; Thu, 07 Sep 2006 12:34:33 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.628.4; Thu, 7 Sep 2006 09:34:30 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Thu, 7 Sep 2006 09:34:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] prefixes for date variants Date: Thu, 7 Sep 2006 09:34:11 -0700 Message-ID: In-Reply-To: <20060907161134.GM14450@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] prefixes for date variants thread-index: AcbSmFbxLmnQQHawRo2f10w9nEQQlQAAoLSg From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 07 Sep 2006 16:34:27.0961 (UTC) FILETIME=[7CA54E90:01C6D29B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org A validating parser when a developer is creating tags for use in some implementation -- there is no immediate DoS scenario, and they'd get warned of the need to check tags that may not be conformant. Peter (two of those who claims he can count :-) > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: Thursday, September 07, 2006 9:12 AM > To: Randy Presuhn > Cc: LTRU Working Group > Subject: Re: [Ltru] prefixes for date variants >=20 > Randy Presuhn scripsit: >=20 > > Consequently, as a technical contributor I think "utilizing an outdated > > copy" should be considered an extremely likely scenario. Furthermore, > > it may be worth thinking about when (if ever) a validating processor > > is really needed. >=20 > A validating parser will be useful in validating a process's output > (be conservative in what you send) rather than its input (be liberal > in what you accept). >=20 > -- > There are three kinds of people in the world: John Cowan > those who can count, cowan@ccil.org > and those who can't. >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 07 12:57:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLNBl-0002Ov-1s; Thu, 07 Sep 2006 12:57:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLNBk-0002Oq-8w for ltru@ietf.org; Thu, 07 Sep 2006 12:57:16 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLNBi-0003P3-Un for ltru@ietf.org; Thu, 07 Sep 2006 12:57:16 -0400 Received: from [172.21.232.245] (wlanvpn-abc-232-245.corp.yahoo.com [172.21.232.245]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k87Gv95t065801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Sep 2006 09:57:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=oWMcdE05CNcIbGAY3uQWwg+gAtZdYwjhD6osaEkxAdylfBo4n8g5BQVv3gufPsJX Message-ID: <45004F64.1020808@yahoo-inc.com> Date: Thu, 07 Sep 2006 09:57:08 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] prefixes for date variants (was Re: Generic variantsandArmenian dialects) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > But it seems to me we're talking about *tag* validation, not *subtag* > validation, yet your response pertains to subtag validation. If that was > the issue, then all that matters is whether the subtag is known. But > because we're talking about tag validation, while the subtag may be > known the particular usage -- the entire tag -- is not. And rejection in > that case is no different than rejecting usage of a tag due to an > unknown subtag. > If we were to create a true generic variant, the later registration of a prefix for that variant would potentially invalidate tags that had previously been valid. That's the hypothetical case we'd be fixing. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 07 16:30:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLQVv-0006oX-NT; Thu, 07 Sep 2006 16:30:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLQVu-0006oN-5U for ltru@ietf.org; Thu, 07 Sep 2006 16:30:18 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLQVq-000500-T6 for ltru@ietf.org; Thu, 07 Sep 2006 16:30:18 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Thu, 7 Sep 2006 13:30:14 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Thu, 7 Sep 2006 13:30:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] prefixes for date variants (was Re: Generic variantsandArmenian dialects) Date: Thu, 7 Sep 2006 13:30:02 -0700 Message-ID: In-Reply-To: <45004F64.1020808@yahoo-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] prefixes for date variants (was Re: Generic variantsandArmenian dialects) thread-index: AcbSnvQO7qX8Gy8sRMOllsvB4ws4sAAHO1Cw From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 07 Sep 2006 20:30:10.0046 (UTC) FILETIME=[69FC39E0:01C6D2BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Addison Phillips [mailto:addison@yahoo-inc.com] > If we were to create a true generic variant, the later registration of a > prefix for that variant would potentially invalidate tags that had > previously been valid. That's the hypothetical case we'd be fixing. Eh? Suppose at T1 "western" is registered with one prefix, "hy". Thus at T1 hy-western =3D good en-western =3D bad Then at T2 > T1 "western" is updated to add a second prefix, "en". So post-T2 validator: hy-western =3D good en-western =3D good pre-T2 validator: hy-western =3D good en-western =3D bad So? Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 07 17:23:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLRL0-0002Xo-Au; Thu, 07 Sep 2006 17:23:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLRKz-0002Xj-U1 for ltru@lists.ietf.org; Thu, 07 Sep 2006 17:23:05 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLRKw-0001gw-Jq for ltru@lists.ietf.org; Thu, 07 Sep 2006 17:23:05 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GLRKO-000796-13 for ltru@lists.ietf.org; Thu, 07 Sep 2006 23:22:28 +0200 Received: from 212.82.251.225 ([212.82.251.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Sep 2006 23:22:28 +0200 Received: from nobody by 212.82.251.225 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Sep 2006 23:22:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 07 Sep 2006 23:20:25 +0200 Organization: Lines: 23 Message-ID: <45008D19.368D@xyzzy.claranet.de> References: <45004F64.1020808@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.225 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Ltru] Re: prefixes for date variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: >> If we were to create a true generic variant ^^^^^^^^^^^^ > So? No, your example was "pseudo-generic": Addison (apparently) discussed true generic variants: Mark had explained here why the 3066bis rules won't allow to downgrade "true generic" to "pseudo-generic": At T1 all what-Ever-generic were allowed. And at T2 after T1 they must be still allowed (= at worst deprecated). Mark proposed that we make that clearer in 3066ter, because it's not obvious. Others proposed that we could just replace one critical SHOULD by MUST to eliminate the possibility of any "true generic" variants. Folks insisting on it can still create an extension registry for their generic purposes. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 07 17:39:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLRb4-0000Y9-4O; Thu, 07 Sep 2006 17:39:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLRb2-0000Xy-I3 for ltru@ietf.org; Thu, 07 Sep 2006 17:39:40 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLRb1-0005dY-80 for ltru@ietf.org; Thu, 07 Sep 2006 17:39:40 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k87LdPDD080592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Sep 2006 14:39:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=OMtRjRKz00Z5CrfR81cg2zPKxUnLWsu0MhlBo5N/OU0snrkH/rp2jQrc3JAJnULT Message-ID: <4500918D.9020302@yahoo-inc.com> Date: Thu, 07 Sep 2006 14:39:25 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] prefixes for date variants (was Re: Generic variantsandArmenian dialects) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Suppose at T1 "western" is registered with *NO" prefix (i.e. my "true generic"). At T1: en-western = good hy-western = good At T2, add prefix "hy": en-western = bad // argh! hy-western = good This violates the idea that once a tag is valid, it is always valid. QED. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 07 18:16:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLSAi-0006K5-JW; Thu, 07 Sep 2006 18:16:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLSAh-0006Jy-8q for ltru@ietf.org; Thu, 07 Sep 2006 18:16:31 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLSAg-0000NS-06 for ltru@ietf.org; Thu, 07 Sep 2006 18:16:31 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Thu, 7 Sep 2006 15:16:29 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Thu, 7 Sep 2006 15:16:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] prefixes for date variants (was Re: Generic variantsandArmenian dialects) Date: Thu, 7 Sep 2006 15:15:53 -0700 Message-ID: In-Reply-To: <4500918D.9020302@yahoo-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] prefixes for date variants (was Re: Generic variantsandArmenian dialects) thread-index: AcbSxiiPbu31/IkkSCKb3pfsVnJchwABLMZg From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 07 Sep 2006 22:16:21.0101 (UTC) FILETIME=[3F6E11D0:01C6D2CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Suppose at T1 "western" is registered with *NO" prefix (i.e. my "true > generic"). At T1: Ah! Well, we long ago concluded that a true generic couldn't get it's usage restricted, right? So once a *true* generic always a true generic. But a true generic doesn't have any prefixes specified. (IIRC that was the whole point of a thread discussed a couple of weeks ago.) Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 02:37:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLZz1-0000Wc-CM; Fri, 08 Sep 2006 02:36:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLZz0-0000WX-Bb for ltru@ietf.org; Fri, 08 Sep 2006 02:36:58 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLZyy-0000C6-4P for ltru@ietf.org; Fri, 08 Sep 2006 02:36:58 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GLZyv-0006VL-Nl for ltru@ietf.org; Fri, 08 Sep 2006 02:36:53 -0400 Date: Fri, 8 Sep 2006 02:36:53 -0400 To: ltru@ietf.org Message-ID: <20060908063653.GH11448@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ltru] 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I'd like to propose a deviation from the proposed rules for languages encompassed by a macrolanguage. Currently, we've been assuming that such languages (including sign languages for this purpose) would be assigned extlang tags, with a prefix representing the language subtag (639-2 or 639-1 code element) for the macrolanguage that encompasses them. Thus ar (Arabic) is a macrolanguage, and the various encompassed languages would be encoded as ar-abh, ar-abv, etc. etc. Likewise, hmn (Hmong) is also a macrolanguage, so we'd get hmn-blu, hmn-hea, etc. *However* (and I think this has always been "understood" but not expressed) this would *not* apply to any encompassed language that already has a language tag as a consequence of being in 639-1 or 639-2 already. Thus sr, not sh-sr; nn, not no-nn. Just wanted to get that on record. -- Verbogeny is one of the pleasurettes John Cowan of a creatific thinkerizer. http://www.ccil.org/~cowan -- Peter da Silva _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 03:00:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLaLu-0001J9-9y; Fri, 08 Sep 2006 03:00:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLaLt-0001Ir-Vd for ltru@ietf.org; Fri, 08 Sep 2006 03:00:37 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLaLq-0005bK-Mx for ltru@ietf.org; Fri, 08 Sep 2006 03:00:37 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Fri, 8 Sep 2006 00:00:33 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Fri, 8 Sep 2006 00:00:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] 3066ter encompassed languages Date: Thu, 7 Sep 2006 23:59:38 -0700 Message-ID: In-Reply-To: <20060908063653.GH11448@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] 3066ter encompassed languages thread-index: AcbTEUGN/DkYlGCiT5uSoy9UKdospAAAuNXQ From: Peter Constable To: X-OriginalArrivalTime: 08 Sep 2006 07:00:30.0742 (UTC) FILETIME=[78E07360:01C6D314] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: John Cowan [mailto:cowan@ccil.org] > I'd like to propose a deviation from the proposed rules for languages > encompassed by a macrolanguage... > Just wanted to get that on record. +1 (I've had this assumption in the back of my mind all along, but it = did need to be stated explicitly at some point.) Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 03:09:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLaUJ-0004uP-4a; Fri, 08 Sep 2006 03:09:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLaUI-0004uK-Cn for ltru@ietf.org; Fri, 08 Sep 2006 03:09:18 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLaUH-0006ek-4q for ltru@ietf.org; Fri, 08 Sep 2006 03:09:18 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060908070911.GYDB22989.mta10.adelphia.net@DGBP7M81> for ; Fri, 8 Sep 2006 03:09:11 -0400 Message-ID: <003d01c6d315$aeaac940$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 8 Sep 2006 00:09:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Ltru] Re: prefixes for date variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: >> Existing tag processors will reject the new tags only if they are >> utilizing an outdated copy of the Registry. Such a processor would >> also reject the now-valid tag "zza" if its copy of the Registry is >> older than 2006-08-29. The same situation applies to variant >> prefixes. > ... > > A reminder - the registry draft says: > > Although the specification of valid subtags for an extension (see: > Section 3.7) MUST be available over the Internet, implementations > SHOULD NOT mechanically depend on it being always accessible, to > prevent denial-of-service attacks. That passage specifically refers to extension subtags, which would be available at whatever URL was specified in the RFC that defines the extension. It's true that processors are not expected to go out to the IANA site and download a new Registry on every usage. (This isn't necessary anyway, since an application can check if its copy is up-to-date by retrieving the File-Date record from IANA -- only 23 bytes, including CRLF -- and comparing it with the local copy.) > Consequently, as a technical contributor I think "utilizing an > outdated copy" should be considered an extremely likely scenario. > Furthermore, it may be worth thinking about when (if ever) a > validating processor is really needed. The point I was trying to make was that the problem is not unique to variant prefixes; it applies to all subtags. Addison pointed out that the effect is different for pure generic variants, born without a prefix, but then I don't think those are such a hot idea anyway. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ Editor, draft-ietf-ltru-initial _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 03:31:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLaps-0006Ip-B6; Fri, 08 Sep 2006 03:31:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLapq-0006Fa-RD for ltru@ietf.org; Fri, 08 Sep 2006 03:31:34 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLapo-0001ds-Fu for ltru@ietf.org; Fri, 08 Sep 2006 03:31:34 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060908073131.TUMN29000.mta13.adelphia.net@DGBP7M81> for ; Fri, 8 Sep 2006 03:31:31 -0400 Message-ID: <004301c6d318$cd9556b0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 8 Sep 2006 00:31:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Ltru] Re: 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > *However* (and I think this has always been "understood" but not > expressed) this would *not* apply to any encompassed language that > already has a language tag as a consequence of being in 639-1 or 639-2 > already. Thus sr, not sh-sr; nn, not no-nn. > > Just wanted to get that on record. This sounds to me like case number 5 from John's fine summary of August 28: http://www1.ietf.org/mail-archive/web/ltru/current/msg05265.html Now that the new charter has been approved, and the due dates for first drafts were *NOT* extended as I requested, we have only 21 days to put together some 3066ter documents. In order for me to build a registry-initialization draft, we need to determine the rules (as John has done here for one such rule). This includes, at a minimum: 1. what to do about the Description fields when the 639-2 and 639-3 descriptions don't match exactly 2. what to do about sign languages 3. which grandfathered tags to deprecate in favor of new 639-3-based subtags (John tackled this in msg05281.html but I'm not sure about some of his conclusions) -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ Editor, draft-ietf-ltru-initial _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 04:54:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLc8N-0007Br-Oq; Fri, 08 Sep 2006 04:54:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLc8L-0007AC-OQ for ltru@lists.ietf.org; Fri, 08 Sep 2006 04:54:45 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLc8K-0001pO-EU for ltru@lists.ietf.org; Fri, 08 Sep 2006 04:54:45 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GLc87-0003Rn-Lz for ltru@lists.ietf.org; Fri, 08 Sep 2006 10:54:32 +0200 Received: from pd9fba97e.dip0.t-ipconnect.de ([217.251.169.126]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Sep 2006 10:54:31 +0200 Received: from nobody by pd9fba97e.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Sep 2006 10:54:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 08 Sep 2006 10:49:18 +0200 Organization: Lines: 36 Message-ID: <45012E8E.5428@xyzzy.claranet.de> References: <004301c6d318$cd9556b0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba97e.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ltru] Re: 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > the due dates for first drafts were *NOT* extended as I > requested, we have only 21 days to put together some 3066ter > documents. Don't take these dates *too* serious, no angry ADs asking Randy and Martin why LTRU is out of line if that takes a few weeks longer - but admittedly I was ashamed when I stumbled over an IESG narrative report with a DISCUSS for an ABNF issue in the matching draft. Let's please get the ABNF right in 3066ter before Last Call. (If we touch the ABNF at all, unlikely) > we need to determine the rules Yes. Don't touch anything in the existing registry unless it is grandfathered or a variant. Downgrading language tags to extlang-s is out. > 1. what to do about the Description fields when the 639-2 > and 639-3 descriptions don't match exactly Keep as is, 639-2 as primary source, 639-3 as supplemental. > 2. what to do about sign languages Would a decree that sgn is a pseudo-macrolanguage help ? IIRC there's no chance that sgn will ever be used for something else > 3. which grandfathered tags to deprecate in favor of new > 639-3-based subtags Same procedure as for grandfathered tags replaced by 639-2 tags Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 09:34:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLgUW-0004Fk-N8; Fri, 08 Sep 2006 09:33:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLgUV-0004Fe-WC for ltru@ietf.org; Fri, 08 Sep 2006 09:33:56 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLgUU-0002Du-La for ltru@ietf.org; Fri, 08 Sep 2006 09:33:55 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060908133354.BOMZ2942.mta9.adelphia.net@DGBP7M81> for ; Fri, 8 Sep 2006 09:33:54 -0400 Message-ID: <005101c6d34b$6d009340$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Fri, 8 Sep 2006 06:33:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: [Ltru] Re: 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> the due dates for first drafts were *NOT* extended as I requested, we >> have only 21 days to put together some 3066ter documents. > > Don't take these dates *too* serious, no angry ADs asking Randy and > Martin why LTRU is out of line if that takes a few weeks longer - but > admittedly I was ashamed when I stumbled over an IESG narrative report > with a DISCUSS for an ABNF issue in the matching draft. Let's please > get the ABNF right in 3066ter before Last Call. (If we touch the ABNF > at all, unlikely) I hope we don't touch it. We went to some lengths to build a syntax that would also work for 3066ter. > Yes. Don't touch anything in the existing registry unless it is > grandfathered or a variant. Downgrading language tags to extlang-s is > out. OK, I think we at least have that one worked out. >> 1. what to do about the Description fields when the 639-2 and 639-3 >> descriptions don't match exactly > > Keep as is, 639-2 as primary source, 639-3 as supplemental. Scenario: We have "Church Slavic" plus 4 other variants. 639-3 adds an inverted form, "Slavic, Church". I assume we add it; first or last? Scenario: We have "Malay". 639-3 changes this to "Malay (specific)" because there is also "Malay (specific)" plus a host of others such as "Malay, Ambonese". I assume we REPLACE the existing description with the one from 639-3. Scenario: We have "Ainu". 639-3 changes this to "Ainu (Japan)" to differentiate it from the unrelated "Ainu (China)". Same outcome as above, plus we should probably point out in the registry update draft that these parenthesized country names are there to disambiguate colliding language names and not to take the place of region subtags. Scenario: We have "Marshallese" and 639-3 changes this to "Marshall" for no immediately obvious reason. I assume we add it; first or last? Scenario: We have "Luxembourgish" followed by "Letzeburgesch". 639-3 reverses the order. I know many have said order doesn't matter, and I suspect we will do nothing here In my private testing I've put the new 639-3 descriptions first and changed ordering to favor 639-3 (making the more comprehensive 639-3 the primary source and 639-2 supplemental). Doing it Frank's way results in fewer gratuitous changes to ordering, but sometimes ("Malay") it is fairly clear we need to replace the existing string. >> 2. what to do about sign languages > > Would a decree that sgn is a pseudo-macrolanguage help ? IIRC there's > no chance that sgn will ever be used for something else It's our "decree," our decision to make. That's what I'm asking for. We also need to decree that "sgn-US" et al. will be deprecated in favor of "sgn-ase" et al., or provide an alternative. And we may need to decide what to do about "sgn-BE-fr" and other sign languages that Michael mentions on his page but that aren't in 639-3. >> 3. which grandfathered tags to deprecate in favor of new 639-3-based >> subtags > > Same procedure as for grandfathered tags replaced by 639-2 tags john suggested deprecating "i-enochian" and "i-mingo" but didn't have anything to replace them with. We probably shouldn't deprecate tags for "real" languages (cf. "zh-min") unless we provide a better way to tag them. And he suggested deprecating "i-tao" (Tao) with "tao" (Yami) and "i-tay" (Tayal) with "tal" (Tal), which weren't at all obvious to me. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ Editor, draft-ietf-ltru-initial _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 10:07:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLh1J-0000ge-5s; Fri, 08 Sep 2006 10:07:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLh1I-0000gZ-Cc for ltru@ietf.org; Fri, 08 Sep 2006 10:07:48 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLh1H-0004hp-4W for ltru@ietf.org; Fri, 08 Sep 2006 10:07:48 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GLh1E-00010N-LV; Fri, 08 Sep 2006 10:07:44 -0400 Date: Fri, 8 Sep 2006 10:07:44 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: 3066ter encompassed languages Message-ID: <20060908140744.GB22017@ccil.org> References: <004301c6d318$cd9556b0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004301c6d318$cd9556b0$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > This sounds to me like case number 5 from John's fine summary of August > 28: > http://www1.ietf.org/mail-archive/web/ltru/current/msg05265.html That summary had to do with the steady-state RFC 3066ter regime; this point has to do with the transition period when we are getting all the 639-3 code elements into the registry. It looks like these rules will do it: 1) If a 639-3 code element is already in the registry, either as itself or in the form of its 639-1 equivalent, do nothing. 2) If a 639-3 code element represents an unencompassed individual language (or a macrolanguage, but fortunately there are no such cases), add it to the registry as a language subtag. 3) If a 639-3 code element represents an individual language encompassed by a macrolanguage, add it to the registry as an extlang subtag, and specify the required prefix to be the language subtag in place for that macrolanguage. For this purpose, all sign languages are treated as if encompassed by the macrolanguage "sgn", which is part of 639-2 and the registry but is not in 639-3. > 1. what to do about the Description fields when the 639-2 and 639-3 > descriptions don't match exactly Keep both. The 639-3 descriptions have been reviewed more recently and are more likely to be correct, especially with regard to diacritics; the 639-2 descriptions should be effectively grandfathered. > 2. what to do about sign languages As above: treat them as encompassed by the macrolanguage "sgn", and therefore add them as extlang subtags. Deprecate the grandfathered equivalents. > 3. which grandfathered tags to deprecate in favor of new 639-3-based > subtags (John tackled this in msg05281.html but I'm not sure about some > of his conclusions) Start picking nits, then. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Is it not written, "That which is written, is written"? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 10:28:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhLW-0001Xa-35; Fri, 08 Sep 2006 10:28:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhLV-0001XU-3T for ltru@lists.ietf.org; Fri, 08 Sep 2006 10:28:41 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLhLT-0008A8-Bu for ltru@lists.ietf.org; Fri, 08 Sep 2006 10:28:41 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GLhLB-0000dl-EX for ltru@lists.ietf.org; Fri, 08 Sep 2006 16:28:21 +0200 Received: from du-017-187.access.de.clara.net ([212.82.246.187]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Sep 2006 16:28:21 +0200 Received: from nobody by du-017-187.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Sep 2006 16:28:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 08 Sep 2006 16:27:17 +0200 Organization: Lines: 86 Message-ID: <45017DC5.4653@xyzzy.claranet.de> References: <005101c6d34b$6d009340$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-017-187.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Subject: [Ltru] Re: 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: >> (If we touch the ABNF at all, unlikely) > I hope we don't touch it. We went to some lengths to build a > syntax that would also work for 3066ter. I'd make an exception if turns out to be unnecessary. > Scenario: We have "Church Slavic" plus 4 other variants. > 639-3 adds an inverted form, "Slavic, Church". I assume we > add it; first or last? The source for Church Slavic was 639-2. I'd stick to it as is in the registry, don't add it. > Scenario: We have "Malay". 639-3 changes this to "Malay > (specific)" because there is also "Malay (specific)" plus a > host of others such as "Malay, Ambonese". If we can also get away with keeping the 639-2 Malay as is... adding a comment with the more specific name is an option. For the future (not the initial bulk update) the review list could figure out what's best. E.g. add it if really needed. For the bulk update: How many conflicts are there ? > I assume we REPLACE the existing description with the one > from 639-3. I don't like that, so far the description always mirrors the source. "No creative corrections of dubious apostrophes" was an example. > Scenario: We have "Ainu". 639-3 changes this to "Ainu > (Japan)" to differentiate it from the unrelated "Ainu > (China)". Same outcome as above Yes, 639-3 shouldn't change 639-2 indirectly via the registry. > we should probably point out in the registry update draft > that these parenthesized country names are there to > disambiguate colliding language names and not to take the > place of region subtags. ACK. > We have "Marshallese" and 639-3 changes this to "Marshall" > for no immediately obvious reason. 639-2 was the primary source, keep as is. > Scenario: We have "Luxembourgish" followed by > "Letzeburgesch". 639-3 reverses the order. Keep as is. 639-3 is supplemental, not an override. > We also need to decree that "sgn-US" et al. will be > deprecated in favor of "sgn-ase" et al. I hope these cases are obvious for you or somebody else here, they're not for me. > john suggested deprecating "i-enochian" and "i-mingo" but > didn't have anything to replace them with. Dubious idea under 4646-rules, there's some MUSTard saying that "Preferred-Value" can't be added after deprecation. I see no compelling reason to change that rule. > he suggested deprecating "i-tao" (Tao) with "tao" (Yami) and > "i-tay" (Tayal) with "tal" (Tal), which weren't at all > obvious to me. Also not for me, but if we find a somewhat reliable source to justify this it's okay. That's how we got Suppress-Scripts, I expected interesting debates and reviews in the Last Call, but unfortunately nothing happened. For a first impression (and draft) you can take any consistent rules, we then look in the output, especially into all changes wrt existing tags, and if it's dubious tune the rules until the output passes giggle tests (not the "Church, Slavic" example). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 10:36:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhTK-0003o1-OM; Fri, 08 Sep 2006 10:36:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhTJ-0003nw-KK for ltru@ietf.org; Fri, 08 Sep 2006 10:36:45 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLhTF-0000UP-Dw for ltru@ietf.org; Fri, 08 Sep 2006 10:36:45 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GLhTE-0001oh-K6; Fri, 08 Sep 2006 10:36:40 -0400 Date: Fri, 8 Sep 2006 10:36:40 -0400 To: ietf-languages@iana.org, ltru@ietf.org Message-ID: <20060908143640.GE22017@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.4 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] RFC 4646!! X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org "O frabjous day! / Callooh, callay!" / He chortled in his joy. Our beloved RFC-3066bis now has an RFC number, or two of them actually: RFC 4646 (BCP 47), "Tags for Identifying Languages", and RFC 4647 (BCP 47), "Matching of Language Tags". Still no sign of the text itself on isi.edu, rfc-editor.org, or ietf.org, though. So we are now doing not RFC3066ter but RFC4646bis. -- Andrew Watt on Microsoft: John Cowan Never in the field of human computing cowan@ccil.org has so much been paid by so many http://www.ccil.org/~cowan to so few! (pace Winston Churchill) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 10:41:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhY3-00070n-1x; Fri, 08 Sep 2006 10:41:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhY2-00070h-3V for ltru@ietf.org; Fri, 08 Sep 2006 10:41:38 -0400 Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLhY0-0000p7-MY for ltru@ietf.org; Fri, 08 Sep 2006 10:41:38 -0400 Received: from eupig2 (unverified [129.1.30.40]) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Fri, 8 Sep 2006 14:41:29 +0000 Received: from lonsmsxb01.emea.ime.reuters.com ([10.14.113.6]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31217) with ESMTP id <0J5A002U43H50N@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Fri, 08 Sep 2006 14:41:29 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Fri, 08 Sep 2006 15:41:29 +0100 Date: Fri, 08 Sep 2006 15:40:43 +0100 From: Misha Wolf Subject: RE: [Ltru] RFC 4646!! To: ltru@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] RFC 4646!! Thread-Index: AcbTVFWkJznS9zQgSoOivHsje3/4dwAAD32A Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Sep 2006 14:41:29.0502 (UTC) FILETIME=[DEC84BE0:01C6D354] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org So we have the traditional two 6's, albeit not as closely coupled as in the past. Misha -----Original Message----- From: John Cowan [mailto:cowan@ccil.org]=20 Sent: 08 September 2006 15:37 To: ietf-languages@iana.org; ltru@ietf.org Subject: [Ltru] RFC 4646!! "O frabjous day! / Callooh, callay!" / He chortled in his joy. Our beloved RFC-3066bis now has an RFC number, or two of them actually: RFC 4646 (BCP 47), "Tags for Identifying Languages", and RFC 4647 (BCP 47), "Matching of Language Tags". Still no sign of the text itself on isi.edu, rfc-editor.org, or ietf.org, though. So we are now doing not RFC3066ter but RFC4646bis. --=20 Andrew Watt on Microsoft: John Cowan Never in the field of human computing cowan@ccil.org has so much been paid by so many http://www.ccil.org/~cowan to so few! (pace Winston Churchill) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 10:49:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhfP-0001Rz-Cw; Fri, 08 Sep 2006 10:49:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhfO-0001Ru-S8 for ltru@lists.ietf.org; Fri, 08 Sep 2006 10:49:14 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLhfN-0001L3-JH for ltru@lists.ietf.org; Fri, 08 Sep 2006 10:49:14 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GLheq-0005zT-2V for ltru@lists.ietf.org; Fri, 08 Sep 2006 16:48:40 +0200 Received: from du-017-187.access.de.clara.net ([212.82.246.187]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Sep 2006 16:48:40 +0200 Received: from nobody by du-017-187.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Sep 2006 16:48:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 08 Sep 2006 16:47:59 +0200 Organization: Lines: 7 Message-ID: <4501829F.5AD6@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-017-187.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Ltru] Re: RFC 4646!! X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Misha Wolf wrote: > we have the traditional two 6's, albeit not as closely > coupled as in the past. Good mnemonic for BCP 47. Curious if Doug got 4648: Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 11:19:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLi95-0003dw-H5; Fri, 08 Sep 2006 11:19:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLi94-0003dN-EY for ltru@ietf.org; Fri, 08 Sep 2006 11:19:54 -0400 Received: from mail06.svc.cra.dublin.eircom.net ([159.134.118.22]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GLi93-0005Nc-5u for ltru@ietf.org; Fri, 08 Sep 2006 11:19:54 -0400 Received: (qmail 60046 messnum 2908421 invoked from network[194.125.174.21/ts09-021.dublin.indigo.ie]); 8 Sep 2006 15:19:51 -0000 Received: from ts09-021.dublin.indigo.ie (HELO ?194.125.174.21?) (194.125.174.21) by mail06.svc.cra.dublin.eircom.net (qp 60046) with SMTP; 8 Sep 2006 15:19:51 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] RFC 4646!! Date: Fri, 8 Sep 2006 16:17:54 +0000 To: ltru@ietf.org X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On 8 Sep 2006, at 14:40, Misha Wolf wrote: > So we have the traditional two 6's, albeit not as closely coupled =20 > as in > the past. > > Misha > Try this, for close coupling: 4 6 4 6 4 + 6 =3D 10 4 + 6 =3D 10 (base 10) 1 + 0 =3D 1 1 + 0 =3D 1 (base 10) 1 + 1 =3D ? (binary) I let someone else do the rest of that sum, this fine sunny day in =20 Ireland.:-) mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 11:24:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLiDC-0004Ju-2T; Fri, 08 Sep 2006 11:24:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLiDA-0004Jp-Sh for ltru@ietf.org; Fri, 08 Sep 2006 11:24:08 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLiD7-0005wh-J6 for ltru@ietf.org; Fri, 08 Sep 2006 11:24:08 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Fri, 8 Sep 2006 08:24:04 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Fri, 8 Sep 2006 08:24:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: 3066ter encompassed languages Date: Fri, 8 Sep 2006 08:23:39 -0700 Message-ID: In-Reply-To: <005101c6d34b$6d009340$6401a8c0@DGBP7M81> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: 3066ter encompassed languages thread-index: AcbTS4eNkVCQB5ioTeK2RXNDa4XfywADhDMw From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 08 Sep 2006 15:24:02.0437 (UTC) FILETIME=[D0734350:01C6D35A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Doug Ewell [mailto:dewell@adelphia.net] > Scenario: We have "Church Slavic" plus 4 other variants. 639-3 adds an > inverted form, "Slavic, Church". I assume we add it; first or last? Perhaps we have a working convention that we only use non-inverted name forms in the Description field. The inverted forms are useful only when providing a sorted list for human-eader lookup, and that is not relevant for the description fields. > Scenario: We have "Marshallese" and 639-3 changes this to "Marshall" > for no immediately obvious reason. I assume we add it; first or last? I believe work is being done to fix such minor inconsistencies. > Scenario: We have "Luxembourgish" followed by "Letzeburgesch". 639-3 > reverses the order. I know many have said order doesn't matter, and I > suspect we will do nothing here Indeed, order doesn't matter. =20 > >> 2. what to do about sign languages > > > > Would a decree that sgn is a pseudo-macrolanguage help ? IIRC there's > > no chance that sgn will ever be used for something else >=20 > It's our "decree," our decision to make. That's what I'm asking for. +1 > We also need to decree that "sgn-US" et al. will be deprecated in favor > of "sgn-ase" et al.,=20 +1 > or provide an alternative.=20 -1 > And we may need to > decide what to do about "sgn-BE-fr" and other sign languages that > Michael mentions on his page but that aren't in 639-3. Someone should prepare proposals to get them added to 639-3; in the mean time, those tags remain grandfathered until such time as there is a syntax-conformant tag that can supersede it. =20 > >> 3. which grandfathered tags to deprecate in favor of new 639-3-based > >> subtags > > > > Same procedure as for grandfathered tags replaced by 639-2 tags >=20 > john suggested deprecating "i-enochian" and "i-mingo" but didn't have > anything to replace them with. We probably shouldn't deprecate tags for > "real" languages (cf. "zh-min")=20 zh-min isn't an individual language; it's a putative genetic sub-family of Chinese. We should deprecate that. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 11:28:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLiHR-0005JG-J7; Fri, 08 Sep 2006 11:28:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLiHQ-0005J2-FI for ltru@lists.ietf.org; Fri, 08 Sep 2006 11:28:32 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLiHP-0006UP-7I for ltru@lists.ietf.org; Fri, 08 Sep 2006 11:28:32 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Fri, 8 Sep 2006 08:28:30 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 08:28:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: 3066ter encompassed languages Date: Fri, 8 Sep 2006 08:27:14 -0700 Message-ID: In-Reply-To: <45017DC5.4653@xyzzy.claranet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: 3066ter encompassed languages thread-index: AcbTUx1aakYLPnIqTQuxZ8TndBiiaAAB/K7A From: Peter Constable To: X-OriginalArrivalTime: 08 Sep 2006 15:28:08.0183 (UTC) FILETIME=[62ED2070:01C6D35B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > For the bulk update: How many conflicts are there ? A final answer cannot be provided until the final draft of the code table for 639-3 is completed. There are still some issues for the JAC to review. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 11:43:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLiVX-0003Co-Ms; Fri, 08 Sep 2006 11:43:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLiVW-0003Ce-Ny for ltru@ietf.org; Fri, 08 Sep 2006 11:43:06 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLiVV-0008G8-DO for ltru@ietf.org; Fri, 08 Sep 2006 11:43:06 -0400 Received: from [10.72.77.4] (snvvpn2-10-72-77-c4.corp.yahoo.com [10.72.77.4]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k88FgaUJ019707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Sep 2006 08:42:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=UQkbq67LYY20ImgdoR3bcQHtc+PI4tjyFVoBYXIFDPqP8+m7wLfBpGQLG1Iz8uOY Message-ID: <45018F6C.8050806@yahoo-inc.com> Date: Fri, 08 Sep 2006 08:42:36 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] 3066ter encompassed languages References: <20060908063653.GH11448@ccil.org> In-Reply-To: <20060908063653.GH11448@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 By the way, since we have a newly minted charter, this weekend I intend to create an updated version of draft-registry as our -00 draft. It will include all the miscellaneous changes made by the RFC Editor as well as slots for ISO 639-3 and initial textual changes (unblocking extlangs, etc.) as discussed on this list or as seem "obvious" from a read-through (such as mentioning 639-3 in the stability rules). Unless the chairs want something else I was intending to call it "draft-ietf-ltru-4646bis" Addison John Cowan wrote: > I'd like to propose a deviation from the proposed rules for languages > encompassed by a macrolanguage. Currently, we've been assuming > that such languages (including sign languages for this purpose) > would be assigned extlang tags, with a prefix representing the > language subtag (639-2 or 639-1 code element) for the macrolanguage > that encompasses them. > > Thus ar (Arabic) is a macrolanguage, and the various encompassed > languages would be encoded as ar-abh, ar-abv, etc. etc. Likewise, > hmn (Hmong) is also a macrolanguage, so we'd get hmn-blu, hmn-hea, > etc. > > *However* (and I think this has always been "understood" but not > expressed) this would *not* apply to any encompassed language > that already has a language tag as a consequence of being in > 639-1 or 639-2 already. Thus sr, not sh-sr; nn, not no-nn. > > Just wanted to get that on record. > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 12:44:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLjSR-00031Q-91; Fri, 08 Sep 2006 12:43:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLjSQ-00031J-IG for ltru@ietf.org; Fri, 08 Sep 2006 12:43:58 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLjSO-0007nI-AC for ltru@ietf.org; Fri, 08 Sep 2006 12:43:58 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GLjSL-0005RD-Sq; Fri, 08 Sep 2006 12:43:53 -0400 Date: Fri, 8 Sep 2006 12:43:53 -0400 To: Marion Gunn Subject: Re: [Ltru] RFC 4646!! Message-ID: <20060908164353.GB21465@ccil.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Marion Gunn scripsit: > Try this, for close coupling: > > 4 6 4 6 > > 4 + 6 = 10 > 4 + 6 = 10 > (base 10) > > 1 + 0 = 1 > 1 + 0 = 1 > (base 10) > > 1 + 1 = ? > (binary) 1 + 1 = 10 (binary) > I let someone else do the rest of that sum, this fine sunny day in > Ireland.:-) Sunny here on the (rather smaller) island I live on, but too sticky-hot for me. When I went to Ireland in 1981, I hit the sunny bit in late August too, most unfortunately for me, as I prefer cool, cloudy, slightly rainy days -- i.e., the whole rest of the year. Sometimes I think Europeans should have avoided the Americas at all costs. We aren't engineered for the climate. -- With techies, I've generally found John Cowan If your arguments lose the first round http://www.ccil.org/~cowan Make it rhyme, make it scan cowan@ccil.org Then you generally can Make the same stupid point seem profound! --Jonathan Robie _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 14:26:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLl3G-0007ww-2E; Fri, 08 Sep 2006 14:26:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLl3E-0007wr-Uv for ltru@ietf.org; Fri, 08 Sep 2006 14:26:04 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLl3C-0006iQ-Nv for ltru@ietf.org; Fri, 08 Sep 2006 14:26:04 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GLl3B-0008DG-VN; Fri, 08 Sep 2006 14:26:02 -0400 Date: Fri, 8 Sep 2006 14:26:01 -0400 To: Stephane Bortzmeyer Subject: Re: [Ltru] Do we need validating parsers for input? (Was: prefixes for date variants Message-ID: <20060908182601.GE21465@ccil.org> References: <013c01c6d246$f8763d40$6401a8c0@DGBP7M81> <001501c6d297$cdf7c6a0$6501a8c0@oemcomputer> <20060907161134.GM14450@ccil.org> <20060907161814.GA24475@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060907161814.GA24475@nic.fr> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer scripsit: > Imagine that a process receives uk-Latb-UA. It is well-formed but not > valid (typo in the script). I presumed that the sender of this tag > would prefer to receive a message "Invalid language tag (subtag Latb > is not registered)" rather than "No document found". Don't you agree? I certainly don't reject this view. I don't know how to decide, without a particular case, whether the benefits of improved error reporting improve the costs of validation. For myself, I primarily think in terms of a publish-subscribe rather than a client-server model, where a document tagger neither knows nor cares exactly who will consume the document, but is concerned that it be correct. -- No, John. I want formats that are actually John Cowan useful, rather than over-featured megaliths that http://www.ccil.org/~cowan address all questions by piling on ridiculous cowan@ccil.org internal links in forms which are hideously over-complex. --Simon St. Laurent on xml-dev _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 15:42:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLmFS-0004pw-Cv; Fri, 08 Sep 2006 15:42:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLmFR-0004pA-B4 for ltru@ietf.org; Fri, 08 Sep 2006 15:42:45 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLm7H-0003qZ-1q for ltru@ietf.org; Fri, 08 Sep 2006 15:34:20 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=E8NtmkF40MmQKCg8C89N1Myi5PImtIlkRnbWK4SgVNkj2Qv9+ryAWChNtUJcaDnY; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.3.121] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GLm7F-0008Gl-Uk for ltru@ietf.org; Fri, 08 Sep 2006 15:34:18 -0400 Message-ID: <00b301c6d37e$3aad1700$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <003d01c6d315$aeaac940$6401a8c0@DGBP7M81> Subject: Re: [Ltru] Re: prefixes for date variants Date: Fri, 8 Sep 2006 12:37:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7afda9b8a0d46cc80c70be9b8f31f084220350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.3.121 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Friday, September 08, 2006 12:09 AM > Subject: [Ltru] Re: prefixes for date variants ... > > Although the specification of valid subtags for an extension (see: > > Section 3.7) MUST be available over the Internet, implementations > > SHOULD NOT mechanically depend on it being always accessible, to > > prevent denial-of-service attacks. > > That passage specifically refers to extension subtags, which would be > available at whatever URL was specified in the RFC that defines the > extension. > > It's true that processors are not expected to go out to the IANA site > and download a new Registry on every usage. (This isn't necessary > anyway, since an application can check if its copy is up-to-date by > retrieving the File-Date record from IANA -- only 23 bytes, including > CRLF -- and comparing it with the local copy.) ... As a technical contributor... If this is how folks understand the words that are there, then we need to make the language much stronger in the update. When an application accesses the registry using HTTP, a lot more than 23 bytes worth of load will be inflicted on IANA's infrastructure, which is why we put the SHOULD NOT language in. The DoS that matters, after all, is the attack on IANA that such an application would inflict. Alternatively, if the WG really believes there will be wide-spread use of validating processors requiring current registrations, then I suggest we might need to reconsider the use of more robust technologies, such as those discussed in conjunction with issues like #893, #965, and #968. (https://rt.psg.com, user and password "ietf") Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 16:19:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLmpN-0003w5-8e; Fri, 08 Sep 2006 16:19:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLmpM-0003vz-OX for ltru@ietf.org; Fri, 08 Sep 2006 16:19:52 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLmpK-0001VH-HR for ltru@ietf.org; Fri, 08 Sep 2006 16:19:52 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GLmpJ-0003bN-Tk; Fri, 08 Sep 2006 16:19:49 -0400 Date: Fri, 8 Sep 2006 16:19:49 -0400 To: Randy Presuhn Subject: Re: [Ltru] RFC 4646!! Message-ID: <20060908201949.GA12963@ccil.org> References: <20060908143640.GE22017@ccil.org> <006301c6d378$db47f460$6501a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006301c6d378$db47f460$6501a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > Uh - when did the announcement go out? I haven't seen it. > I haven't even seen the note from the rfc-editor announcing > their intent to make it available. See http://www.rfc-editor.org/new_rfcs.html . I don't know whether this page is authoritative or not. I also note, belatedly, that it assigns RFC 4645 to the Doug's initial registry -- hopefully only the prose bits, not the record-jar portion. The three links to RFC 464[567] are broken. -- John Cowan http://www.ccil.org/~cowan Raffiniert ist der Herrgott, aber boshaft ist er nicht. --Albert Einstein _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 16:53:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLnLc-0001J9-1z; Fri, 08 Sep 2006 16:53:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLnLa-0001Hp-8w for ltru@ietf.org; Fri, 08 Sep 2006 16:53:10 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLnLZ-0000Bt-2J for ltru@ietf.org; Fri, 08 Sep 2006 16:53:10 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GLnLW-0004cI-Ih; Fri, 08 Sep 2006 16:53:06 -0400 Date: Fri, 8 Sep 2006 16:53:06 -0400 To: Peter Constable Subject: Re: [Ltru] Re: 3066ter encompassed languages Message-ID: <20060908205306.GK21465@ccil.org> References: <005101c6d34b$6d009340$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: +1 to omitting inverted names, order doesn't matter, sgn is treated as a macrolanguage, sgn-XX deprecated. > > And we may need to > > decide what to do about "sgn-BE-fr" and other sign languages that > > Michael mentions on his page but that aren't in 639-3. > > Someone should prepare proposals to get them added to 639-3; in the mean > time, those tags remain grandfathered until such time as there is a > syntax-conformant tag that can supersede it. Ethnologue thinks the difference between sgn-BE-fr and sgn-BE-nl is dialectal. This needs to be hashed out at the 639-3/RA when it is functional. -- A rose by any other name John Cowan may smell as sweet, http://www.ccil.org/~cowan but if you called it an onion cowan@ccil.org you'd get cooks very confused. --RMS _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 17:06:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLnYf-0004Yp-EY; Fri, 08 Sep 2006 17:06:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLnYc-0004Yc-WC for ltru@ietf.org; Fri, 08 Sep 2006 17:06:39 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLnYY-0001zS-Or for ltru@ietf.org; Fri, 08 Sep 2006 17:06:38 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GLnYY-0005xJ-Gf; Fri, 08 Sep 2006 17:06:34 -0400 Date: Fri, 8 Sep 2006 17:06:34 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: 3066ter encompassed languages Message-ID: <20060908210634.GL21465@ccil.org> References: <005101c6d34b$6d009340$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005101c6d34b$6d009340$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > john suggested deprecating "i-enochian" and "i-mingo" but didn't have > anything to replace them with. We probably shouldn't deprecate tags for > "real" languages (cf. "zh-min") unless we provide a better way to tag > them. And he suggested deprecating "i-tao" (Tao) with "tao" (Yami) and > "i-tay" (Tayal) with "tal" (Tal), which weren't at all obvious to me. Enochian is a conlang and needs to be processed through Linguist List, the sub-registrar for conlangs, in order to get incorporated into 639-3 at a later stage. Until then, i-enochian stays. Mingo is either a dialect of Seneca or a separate language, depending on how distinct its orthography is. It's mutually intelligible with Seneca, by direct report. The experts haven't yet weighed in. In any case, we keep i-mingo for now and then either register 'mingo' as a variant subtag with prefix 'see', or else 639-3 registers a new tag. zh-min should just be deprecated: it's a bogus macrolanguage. http://www.ethnologue.com/show_language.asp?code=tao says that Tao is an alternative (and locally preferred) name for Yami. I assume Peter changed the code to "tao" to agree with i-tao. "tal" was a typo on my part: should have been "tay"; so deprecate "i-tay" in favor of "tay". Tayal is a listed alternate name at Ethnologue. -- As you read this, I don't want you to feel John Cowan sorry for me, because, I believe everyone cowan@ccil.org will die someday. http://www.ccil.org/~cowan --From a Nigerian-type scam spam _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 17:16:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLnhi-0007RN-ME; Fri, 08 Sep 2006 17:16:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLnhh-0007RG-CK for ltru@lists.ietf.org; Fri, 08 Sep 2006 17:16:01 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLnhf-0003i8-Ur for ltru@lists.ietf.org; Fri, 08 Sep 2006 17:16:01 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GLnhf-0006CL-Mw for ltru@lists.ietf.org; Fri, 08 Sep 2006 17:15:59 -0400 Date: Fri, 8 Sep 2006 17:15:59 -0400 To: ltru@lists.ietf.org Subject: Re: [Ltru] Re: 3066ter encompassed languages Message-ID: <20060908211559.GM21465@ccil.org> References: <005101c6d34b$6d009340$6401a8c0@DGBP7M81> <45017DC5.4653@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45017DC5.4653@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Scenario: We have "Malay". 639-3 changes this to "Malay > (specific)" because there is also "Malay (specific)" plus a > host of others such as "Malay, Ambonese". In fact it does not. 639-1 "ms" / 639-2 "msa" maps to 639-3's "Malay (generic)", the macrolanguage. The 639-3 "mly" maps to the language called "Malay (specific)"; that is, the individual language encompassed by "ms" that is also confusingly called "Malay". -- A witness cannot give evidence of his John Cowan age unless he can remember being born. cowan@ccil.org --Judge Blagden http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 19:07:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLpRW-0002oM-19; Fri, 08 Sep 2006 19:07:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLpRU-0002oG-IO for ltru@ietf.org; Fri, 08 Sep 2006 19:07:24 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLpRT-0005R3-4u for ltru@ietf.org; Fri, 08 Sep 2006 19:07:24 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=n/+5+yMhelsNskIvN6me9Brzevot+18QGsefPl7cAAwUwQQiqUuAwvkmleDc6toA; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.3.121] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GLpRO-0000Dz-5R for ltru@ietf.org; Fri, 08 Sep 2006 19:07:18 -0400 Message-ID: <001b01c6d39b$fce81e60$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 8 Sep 2006 16:10:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7af59362e258c7ad8696982c6326ee2a776350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.3.121 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [Ltru] Fw: BCP0047 RFC 4646 on Tags for Identifying Languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - Congratulations to all concerned! Randy, ltru co-chair ----- Original Message ----- > From: > To: ; > Cc: > Sent: Friday, September 08, 2006 3:44 PM > Subject: BCP0047 RFC 4646 on Tags for Identifying Languages > > > A new Request for Comments is now available in online RFC libraries. > > BCP0047 > RFC 4646 > > Title: Tags for Identifying Languages > Author: A. Phillips, M. Davis > Status: Best Current Practice > Date: September 2006 > Mailbox: addison@inter-locale.com, > mark.davis@macchiato.com > Pages: 59 > Characters: 135810 > > > I-D Tag: draft-ietf-ltru-registry-14.txt > > URL: http://www.rfc-editor.org/rfc/rfc4646.txt > > 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, in combination with RFC 4647, replaces RFC 3066, which > replaced RFC 1766. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. > > This document is a product of the Language Tag Registry Update > Working Group of the IETF > > This document specifies an Internet Best Current Practices for the > Internet Community, and requests discussion and suggestions for > improvements. Distribution of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 19:08:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLpS7-0002qj-7N; Fri, 08 Sep 2006 19:08:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLpS5-0002qe-TQ for ltru@ietf.org; Fri, 08 Sep 2006 19:08:01 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLpS4-0005bo-J2 for ltru@ietf.org; Fri, 08 Sep 2006 19:08:01 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AbQ9fl0CKu8n8hd5McB1by9MQTmQ/4k4bQEq0sCzAH65lCwHjj04W8eByG72jBhw; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.3.121] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GLpS3-0000qN-Ug for ltru@ietf.org; Fri, 08 Sep 2006 19:08:00 -0400 Message-ID: <002001c6d39c$15f3dca0$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 8 Sep 2006 16:11:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7af95989d4f6548b8050118d2dc4eb43c08350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.3.121 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [Ltru] Fw: BCP0047 RFC 4647 on Matching of Language Tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - Congratulations to all concerned. Randy, ltru co-chair > From: > To: ; > Cc: > Sent: Friday, September 08, 2006 3:45 PM > Subject: BCP0047 RFC 4647 on Matching of Language Tags > > > A new Request for Comments is now available in online RFC libraries. > > BCP0047 > RFC 4647 > > Title: Matching of Language Tags > Author: A. Phillips, M. Davis > Status: Best Current Practice > Date: September 2006 > Mailbox: addison@inter-locale.com, > mark.davis@macchiato.com > Pages: 20 > Characters: 45595 > > > I-D Tag: draft-ietf-ltru-matching-15.txt > > URL: http://www.rfc-editor.org/rfc/rfc4647.txt > > This document describes a syntax, called a "language-range", for > specifying items in a user's list of language preferences. It also > describes different mechanisms for comparing and matching these to > language tags. Two kinds of matching mechanisms, filtering and > lookup, are defined. Filtering produces a (potentially empty) set of > language tags, whereas lookup produces a single language tag. > Possible applications include language negotiation or content > selection. This document, in combination with RFC 4646, replaces RFC > 3066, which replaced RFC 1766. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. > > This document is a product of the Language Tag Registry Update > Working Group of the IETF > > This document specifies an Internet Best Current Practices for the > Internet Community, and requests discussion and suggestions for > improvements. Distribution of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 19:10:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLpUF-0002x3-3v; Fri, 08 Sep 2006 19:10:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLpUD-0002wv-Ub for ltru@ietf.org; Fri, 08 Sep 2006 19:10:13 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLpUB-0006CF-K2 for ltru@ietf.org; Fri, 08 Sep 2006 19:10:13 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=djn5UC8OphI+1n89NjFSN8mbZml/RHC8SOa5d0FvIWBd8OmxIEW7d+AbVe+jJx/u; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.3.121] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GLpUB-0002od-5H for ltru@ietf.org; Fri, 08 Sep 2006 19:10:11 -0400 Message-ID: <002501c6d39c$6428eb40$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 8 Sep 2006 16:13:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7af399687ca9011fa07622d2a13f32c34ed350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.3.121 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: [Ltru] Fw: RFC 4645 on Initial Language Subtag Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - Congratulations, even if the most important part had to disappear upon publication. :-) Randy, ltru co-chair > From: > To: ; > Cc: > Sent: Friday, September 08, 2006 3:44 PM > Subject: RFC 4645 on Initial Language Subtag Registry > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 4645 > > Title: Initial Language Subtag Registry > Author: D. Ewell > Status: Informational > Date: September 2006 > Mailbox: dewell@adelphia.net > Pages: 7 > Characters: 15517 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-ltru-initial-06.txt > > URL: http://www.rfc-editor.org/rfc/rfc4645.txt > > This memo defined the initial contents of the IANA Language Subtag > Registry for use in forming tags for the identification of languages. > Since the contents of this memo only served as a starting point for > the registry, its actual contents have been removed before > publication to avoid confusion. This memo provides information for > the Internet community. > > This document is a product of the Language Tag Registry Update > Working Group of the IETF > > > INFORMATIONAL: This memo provides information for the Internet community. > It does not specify an Internet standard of any kind. Distribution > of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 08 19:26:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLpkB-00047o-1z; Fri, 08 Sep 2006 19:26:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLpkA-00047V-IM; Fri, 08 Sep 2006 19:26:42 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLpk9-0008VS-Bh; Fri, 08 Sep 2006 19:26:42 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=LR+dwhNeHTZo5UA9Vl7of5V9r8O2fqUI1W8iLqr/5Nfelx7AqmQbm4030GLg5SvR; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.3.121] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GLpk8-0001RH-KM; Fri, 08 Sep 2006 19:26:40 -0400 Message-ID: <006b01c6d39e$b1f11c60$6501a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20060908063653.GH11448@ccil.org> <45018F6C.8050806@yahoo-inc.com> <009601c6d37b$962ce2c0$6501a8c0@oemcomputer> Date: Fri, 8 Sep 2006 16:29:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7af2224b0f8dcfcaee20446559b5ae44e40350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.3.121 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: LTRU Working Group Subject: [Ltru] pre-approval for ltru WG -00- internet-draft X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As co-chair of the ltru WG, I approve the impending submission of draft-ietf-ltru-4646bis-00.txt as an ltru working group internet draft. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 00:33:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLuWk-0001s6-Sg; Sat, 09 Sep 2006 00:33:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLuWj-0001s1-OL for ltru@ietf.org; Sat, 09 Sep 2006 00:33:09 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLuWi-0006kI-Eq for ltru@ietf.org; Sat, 09 Sep 2006 00:33:09 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060909043307.UGTM29000.mta13.adelphia.net@DGBP7M81>; Sat, 9 Sep 2006 00:33:07 -0400 Message-ID: <003101c6d3c9$0b484250$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <005101c6d34b$6d009340$6401a8c0@DGBP7M81> <20060908210634.GL21465@ccil.org> Subject: Re: [Ltru] Re: 3066ter encompassed languages Date: Fri, 8 Sep 2006 21:33:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Enochian is a conlang and needs to be processed through Linguist List, > the sub-registrar for conlangs, in order to get incorporated into > 639-3 at a later stage. Until then, i-enochian stays. > > Mingo is either a dialect of Seneca or a separate language, depending > on how distinct its orthography is. It's mutually intelligible with > Seneca, by direct report. The experts haven't yet weighed in. In any > case, we keep i-mingo for now and then either register 'mingo' as a > variant subtag with prefix 'see', or else 639-3 registers a new tag. In your message of August 29 (msg05281) you had labeled both of these "Deprecated in 3066ter" but with a Preferred-Value of "not known." I prefer this more conservative approach. > zh-min should just be deprecated: it's a bogus macrolanguage. Agreed. "cf." was meant to convey that: "real languages, as opposed to zh-min." > http://www.ethnologue.com/show_language.asp?code=tao says that Tao is > an alternative (and locally preferred) name for Yami. I assume Peter > changed the code to "tao" to agree with i-tao. > > "tal" was a typo on my part: should have been "tay"; so deprecate > "i-tay" in favor of "tay". Tayal is a listed alternate name at > Ethnologue. Thanks for doing the research on both of those. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 · UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 01:18:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLvEg-0004sX-2Y; Sat, 09 Sep 2006 01:18:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLvEe-0004rr-I1 for ltru@ietf.org; Sat, 09 Sep 2006 01:18:32 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLv7E-0005v3-Jh for ltru@ietf.org; Sat, 09 Sep 2006 01:10:53 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GLv7E-0005qO-4H; Sat, 09 Sep 2006 01:10:52 -0400 Date: Sat, 9 Sep 2006 01:10:52 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: 3066ter encompassed languages Message-ID: <20060909051051.GH22017@ccil.org> References: <005101c6d34b$6d009340$6401a8c0@DGBP7M81> <20060908210634.GL21465@ccil.org> <003101c6d3c9$0b484250$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003101c6d3c9$0b484250$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > In your message of August 29 (msg05281) you had labeled both of these > "Deprecated in 3066ter" but with a Preferred-Value of "not known." I > prefer this more conservative approach. So do I, now that I have the facts. -- John Cowan http://ccil.org/~cowan cowan@ccil.org Economists were put on this planet to make astrologers look good. --Leo McGarry _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 01:24:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLvJw-0005Xh-GA; Sat, 09 Sep 2006 01:24:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLvEf-0004rr-TN for ltru@ietf.org; Sat, 09 Sep 2006 01:18:33 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLv4r-0005RV-F2 for ltru@ietf.org; Sat, 09 Sep 2006 01:08:26 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060909050823.UVLE29000.mta13.adelphia.net@DGBP7M81> for ; Sat, 9 Sep 2006 01:08:23 -0400 Message-ID: <003901c6d3cd$f8010290$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 8 Sep 2006 22:08:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Ltru] Re: 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > It looks like these rules will do it: > > 1) If a 639-3 code element is already in the registry, either as > itself or in the form of its 639-1 equivalent, do nothing. > > 2) If a 639-3 code element represents an unencompassed individual > language (or a macrolanguage, but fortunately there are no such > cases), add it to the registry as a language subtag. > > 3) If a 639-3 code element represents an individual language > encompassed by a macrolanguage, add it to the registry as an extlang > subtag, and specify the required prefix to be the language subtag in > place for that macrolanguage. For this purpose, all sign languages > are treated as if encompassed by the macrolanguage "sgn", which is > part of 639-2 and the registry but is not in 639-3. This looks good to me. >> 1. what to do about the Description fields when the 639-2 and 639-3 >> descriptions don't match exactly > > Keep both. The 639-3 descriptions have been reviewed more recently > and are more likely to be correct, especially with regard to > diacritics; the 639-2 descriptions should be effectively > grandfathered. I also assumed the 639-3 descriptions would be more likely to be correct. Since others have argued that the order of descriptions doesn't matter, however, we should add any new descriptions after the existing ones. >> 2. what to do about sign languages > > As above: treat them as encompassed by the macrolanguage "sgn", and > therefore add them as extlang subtags. Deprecate the grandfathered > equivalents. OK. >> 3. which grandfathered tags to deprecate in favor of new 639-3-based >> subtags (John tackled this in msg05281.html but I'm not sure about >> some of his conclusions) > > Start picking nits, then. See my previous mail. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 • UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 01:45:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLvev-0002f0-DS; Sat, 09 Sep 2006 01:45:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLvet-0002ev-Be for ltru@ietf.org; Sat, 09 Sep 2006 01:45:39 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLveq-0000KA-WB for ltru@ietf.org; Sat, 09 Sep 2006 01:45:39 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060909054531.VJYR29000.mta13.adelphia.net@DGBP7M81> for ; Sat, 9 Sep 2006 01:45:31 -0400 Message-ID: <004101c6d3d3$283f38f0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 8 Sep 2006 22:45:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Subject: [Ltru] Re: 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> I hope we don't touch it. We went to some lengths to build a syntax >> that would also work for 3066ter. > > I'd make an exception if turns out to be unnecessary. I don't see that happening. John has proposed rules for assigning primary and extended language tags to unencompassed and encompassed languages respectively, and nobody else has seriously objected to this. >> Scenario: We have "Church Slavic" plus 4 other variants. 639-3 adds >> an inverted form, "Slavic, Church". I assume we add it; first or >> last? > > The source for Church Slavic was 639-2. I'd stick to it as is in the > registry, don't add it. What if the descriptions are noticeably different between 639-2 and 639-3? Where do we draw the line without being arbitrary? >> Scenario: We have "Malay". 639-3 changes this to "Malay (specific)" (this was an error, should have been "Malay (generic)") >> because there is also "Malay (specific)" plus a host of others such >> as "Malay, Ambonese". > > If we can also get away with keeping the 639-2 Malay as is... adding a > comment with the more specific name is an option. My opinion is that that will add a lot of confusion and obfuscate the relationship between "generic" Malay and its flavors. > For the future (not the initial bulk update) the review list could > figure out what's best. E.g. add it if really needed. I'd recommend adding it, but you're right: this is an ietf-languages question. > For the bulk update: How many conflicts are there ? I count approximately 16, not including inverted forms like "Newari, Classical" which it has been suggested we ignore. >> I assume we REPLACE the existing description with the one from 639-3. > > I don't like that, so far the description always mirrors the source. > "No creative corrections of dubious apostrophes" was an example. Which source do we mirror, if one says "Waray" and the other says "Waray (Philippines)"? Which is better for avoiding confusion with "Waray (Australia)"? >> Scenario: We have "Ainu". 639-3 changes this to "Ainu (Japan)" to >> differentiate it from the unrelated "Ainu (China)". Same outcome as >> above > > Yes, 639-3 shouldn't change 639-2 indirectly via the registry. In this case 639-3 is not "changing" 639-2, but elaborating on it, adding information which was not present before (partly because "aib" was not in 639-2). >> we should probably point out in the registry update draft that these >> parenthesized country names are there to disambiguate colliding >> language names and not to take the place of region subtags. > > ACK. Bill the Cat? I'm in favor of adding the parenthesized country names introduced in 639-3, when they serve to distinguish two languages with otherwise identical names. (subsequent examples of this issue elided; readers know when Frank and I stand) >> We also need to decree that "sgn-US" et al. will be deprecated in >> favor of "sgn-ase" et al. > > I hope these cases are obvious for you or somebody else here, they're > not for me. Both the grandfathered tag "sgn-US" and the 639-3 code elements "ase" refer to American Sign Language. >> john suggested deprecating "i-enochian" and "i-mingo" but didn't have >> anything to replace them with. > > Dubious idea under 4646-rules, there's some MUSTard saying that > "Preferred-Value" can't be added after deprecation. I see no > compelling reason to change that rule. John withdrew this. > For a first impression (and draft) you can take any consistent rules, > we then look in the output, especially into all changes wrt existing > tags, and if it's dubious tune the rules until the output passes > giggle tests (not the "Church, Slavic" example). That's what we'll end up doing, and it will be fine as long as the rules are consistent and not arbitrary or contrived. The only really exceptional situation that I see is "sgn", and I don't see any difficulty justifying this when you consider the exceptional nature of sign languages. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 • UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 01:58:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLvr5-000313-1l; Sat, 09 Sep 2006 01:58:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLvr3-00030y-Qu for ltru@ietf.org; Sat, 09 Sep 2006 01:58:13 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLvr0-0001Lh-HJ for ltru@ietf.org; Sat, 09 Sep 2006 01:58:13 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060909055809.BXRC2942.mta9.adelphia.net@DGBP7M81> for ; Sat, 9 Sep 2006 01:58:09 -0400 Message-ID: <004601c6d3d4$ec6ea700$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 8 Sep 2006 22:58:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Ltru] Re: 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > Perhaps we have a working convention that we only use non-inverted > name forms in the Description field. The inverted forms are useful > only when providing a sorted list for human-eader lookup, and that is > not relevant for the description fields. I like this, but can we go one step further for consistency, and actually *remove* the existing inverted forms for any subtags that also have the non-inverted form? Type: language Subtag: nd Description: Ndebele, North <-- remove Description: North Ndebele Added: 2005-10-16 Suppress-Script: Latn Type: language Subtag: nds Description: Low German Description: Low Saxon Description: German, Low <-- remove Description: Saxon, Low <-- remove Added: 2005-10-16 I don't see anything in Section 3.4 that prohibits this. Note that I don't propose "un-inverting" any descriptions when the inverted form is all we have: Type: language Subtag: fro Description: French, Old (842-ca. 1400) <-- no change Added: 2005-10-16 >> Scenario: We have "Marshallese" and 639-3 changes this to "Marshall" >> for no immediately obvious reason. I assume we add it; first or >> last? > > I believe work is being done to fix such minor inconsistencies. I know the answer to this already, but it would be nice to know what things like this (and "zza" as macrolanguage) will be changed before the final release of 639-3. We can always plan as if there will be no surprises, and react to those that occur. >> Scenario: We have "Luxembourgish" followed by "Letzeburgesch". >> 639-3 reverses the order. I know many have said order doesn't >> matter, and I suspect we will do nothing here > > Indeed, order doesn't matter. Pretty much everyone seems to agree here. >> And we may need to decide what to do about "sgn-BE-fr" and other sign >> languages that Michael mentions on his page but that aren't in 639-3. > > Someone should prepare proposals to get them added to 639-3; in the > mean time, those tags remain grandfathered until such time as there is > a syntax-conformant tag that can supersede it. Agreed. For 4646bis this means we do nothing for "sgn-BE-fr" and "sgn-BE-nl". John observed that "sgn-CH-de" can be replaced by "sgn-sgg". -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 • UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 02:02:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLvvJ-0001AB-1b; Sat, 09 Sep 2006 02:02:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLvvH-00019j-81 for ltru@ietf.org; Sat, 09 Sep 2006 02:02:35 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLvvF-0001aA-Uw for ltru@ietf.org; Sat, 09 Sep 2006 02:02:35 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060909060233.VPOL29000.mta13.adelphia.net@DGBP7M81> for ; Sat, 9 Sep 2006 02:02:33 -0400 Message-ID: <004a01c6d3d5$897663d0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 8 Sep 2006 23:02:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ltru] How many conflicts? (was: Re: 3066ter encompassed languages) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: >> For the bulk update: How many conflicts are there ? > > A final answer cannot be provided until the final draft of the code > table for 639-3 is completed. There are still some issues for the JAC > to review. I do find it useful to know, as in this example, how many conflicts there would be if today's draft code table were made final. It gives me a good sense of whether there are 5, 50, or 500. We do need to keep in mind that the exact numbers are subject to change. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 • UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 02:17:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLw9k-0005ZF-JX; Sat, 09 Sep 2006 02:17:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLw9k-0005ZA-A2 for ltru@ietf.org; Sat, 09 Sep 2006 02:17:32 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLw9i-0002fu-19 for ltru@ietf.org; Sat, 09 Sep 2006 02:17:32 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060909061725.CEZJ2942.mta9.adelphia.net@DGBP7M81> for ; Sat, 9 Sep 2006 02:17:25 -0400 Message-ID: <005401c6d3d7$9d2c66c0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 8 Sep 2006 23:17:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Ltru] Re: prefixes for date variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: >> It's true that processors are not expected to go out to the IANA site >> and download a new Registry on every usage. (This isn't necessary >> anyway, since an application can check if its copy is up-to-date by >> retrieving the File-Date record from IANA -- only 23 bytes, including >> CRLF -- and comparing it with the local copy.) > ... > > As a technical contributor... > > If this is how folks understand the words that are there, then we need > to make the language much stronger in the update. When an application > accesses the registry using HTTP, a lot more than 23 bytes worth of > load will be inflicted on IANA's infrastructure, which is why we put > the SHOULD NOT language in. The DoS that matters, after all, is the > attack on IANA that such an application would inflict. The load is far less than 630,000 bytes, the projected approximate size of the 4646bis Registry. > Alternatively, if the WG really believes there will be wide-spread use > of validating processors requiring current registrations, then I > suggest we might need to reconsider the use of more robust > technologies, such as those discussed in conjunction with issues like > #893, #965, and #968. (https://rt.psg.com, user and password "ietf") My tag generating and validating app (which I'll make available in the next few days, now that the RFCs are published) uses a local version of the Registry, packaged as a Windows DLL. I update the DLL every time the Registry is changed, and plan to supply the updated DLLs to users for free. That seems to me a reasonable distribution method that takes some degree of burden off the IANA site. I wouldn't be opposed to discussing incremental updating methods of the type Randy referred to. We created a Registry so that users could have a single, uniform repository of all valid subtags. Having an up-to-date copy of the Registry is something that should be encouraged. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 • UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 02:36:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLwS9-00018I-5S; Sat, 09 Sep 2006 02:36:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLwS4-0000g2-3K for ltru@ietf.org; Sat, 09 Sep 2006 02:36:28 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLwE5-0002up-PB for ltru@ietf.org; Sat, 09 Sep 2006 02:22:03 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060909062201.VUWM29000.mta13.adelphia.net@DGBP7M81> for ; Sat, 9 Sep 2006 02:22:01 -0400 Message-ID: <005601c6d3d8$417c7530$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 8 Sep 2006 23:21:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ltru] Re: Fw: RFC 4645 on Initial Language Subtag Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > Congratulations, even if the most important part had to disappear upon > publication. :-) I still think we should investigate whether a new, huge RFC that will be chopped down to 7 pages before publication is the best way to deliver the new 4646bis data to IANA. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 • UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 05:02:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLyip-0002d9-7x; Sat, 09 Sep 2006 05:01:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLyio-0002d4-Cc for ltru@lists.ietf.org; Sat, 09 Sep 2006 05:01:54 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLyik-0003vr-Vs for ltru@lists.ietf.org; Sat, 09 Sep 2006 05:01:54 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GLyiR-0001vZ-Ew for ltru@lists.ietf.org; Sat, 09 Sep 2006 11:01:31 +0200 Received: from pd9fbadaa.dip0.t-ipconnect.de ([217.251.173.170]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Sep 2006 11:01:31 +0200 Received: from nobody by pd9fbadaa.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Sep 2006 11:01:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 09 Sep 2006 11:00:01 +0200 Organization: Lines: 23 Message-ID: <45028291.4588@xyzzy.claranet.de> References: <005601c6d3d8$417c7530$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbadaa.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Ltru] Re: Fw: RFC 4645 on Initial Language Subtag Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > we should investigate whether a new, huge RFC that will be > chopped down to 7 pages before publication is the best way > to deliver the new 4646bis data to IANA. Short RFCs are okay, compare RFC 862 (STD 20). For some time I thought that another way would be better for the bulk update, because it's huge, and the Last Call for RFC 4645 triggered only two reviews (Bruce + JohnK). But since Peter proposed to deprecate zh-min as special case, maybe "4645bis" is the best place to handle such exceptions. We could ask IANA what they prefer, 6000 update templates in a file, 6000 registry entries in a file, or 6000 entries in a "4645bis". If they don't care managing cruft like zh-min in a separate "4645bis" instead of "4646bis" could make sense: Readers of 4646bis are probably not interested in this detail. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 05:50:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLzU7-0005nD-3L; Sat, 09 Sep 2006 05:50:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLzU5-0005n5-L9 for ltru@lists.ietf.org; Sat, 09 Sep 2006 05:50:45 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLzU4-0008Dy-BG for ltru@lists.ietf.org; Sat, 09 Sep 2006 05:50:45 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GLzTt-000333-FJ for ltru@lists.ietf.org; Sat, 09 Sep 2006 11:50:33 +0200 Received: from pd9fbadaa.dip0.t-ipconnect.de ([217.251.173.170]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Sep 2006 11:50:33 +0200 Received: from nobody by pd9fbadaa.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Sep 2006 11:50:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 09 Sep 2006 11:47:58 +0200 Organization: Lines: 43 Message-ID: <45028DCE.75DE@xyzzy.claranet.de> References: <004601c6d3d4$ec6ea700$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbadaa.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Ltru] Description styles (was: 3066ter encompassed languages) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: >> The inverted forms are useful only when providing a sorted >> list for human-eader lookup, and that is not relevant for >> the description fields. > I like this I don't, if I look for say SASL on the IANA page it makes me nervous when it doesn't show up under SA or "se"(curity) - until I finally find it under "si"(mple). Convert registry to table and then sort by description (or by type + description) is a good idea. Why destroy it ? > Type: language > Subtag: nds > Description: Low German > Description: Low Saxon > Description: German, Low <-- remove If somebody looking for "German" in a sorted table immediately sees that there's also "German, Low" it's good. For "Ndebele" and "Ndebele, North" it's probably similar. > I don't propose "un-inverting" any descriptions when the > inverted form is all we have: > Type: language > Subtag: fro > Description: French, Old (842-ca. 1400) <-- no change That would be a mess, sometimes 639-2 style survives, in other cases it's replaced by another (I say worse) style. Stick to 639-2 for primary tags derived from 639-2. John said that the 639-3 descriptions are more up to date in some cases. IMO 639-2 should then adopt it, better apostrophes and all, it's not the job of the IANA registry to second-guess its sources (outside of comments). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 06:18:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLzuS-0007qc-F4; Sat, 09 Sep 2006 06:18:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLzuS-0007qX-0Z for ltru@lists.ietf.org; Sat, 09 Sep 2006 06:18:00 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLzuP-0006It-IP for ltru@lists.ietf.org; Sat, 09 Sep 2006 06:17:59 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GLzuH-0007Rc-LC for ltru@lists.ietf.org; Sat, 09 Sep 2006 12:17:49 +0200 Received: from pd9fbadaa.dip0.t-ipconnect.de ([217.251.173.170]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Sep 2006 12:17:49 +0200 Received: from nobody by pd9fbadaa.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Sep 2006 12:17:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 09 Sep 2006 12:17:22 +0200 Organization: Lines: 62 Message-ID: <450294B2.5319@xyzzy.claranet.de> References: <004101c6d3d3$283f38f0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbadaa.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Subject: [Ltru] Re: 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > John has proposed rules for assigning primary and extended > language tags to unencompassed and encompassed languages > respectively, and nobody else has seriously objected to this. Yes, those were good rules. But if 639-anything is guaranteed to be unique we don't need the extlang construct at all. >> The source for Church Slavic was 639-2. I'd stick to it as >> is in the registry, don't add it. > What if the descriptions are noticeably different between > 639-2 and 639-3? Where do we draw the line without being > arbitrary? The line is "whatever 639-2 says" for a tag derived from 639-2. In that case don't bother to look at 639-3, unless it could be a good comment to be registered individually under 4646 rules. {Malay vs. Malay (generic)] > My opinion is that that will add a lot of confusion and > obfuscate the relationship between "generic" Malay and its > flavors. I'm not confused, Malay 639-2 is what I want. And it's fine if 639-3 Malay (Ambonese) shows up next alphabetically. >> For the bulk update: How many conflicts are there ? > I count approximately 16, not including inverted forms like > "Newari, Classical" which it has been suggested we ignore. Good, so a general rule "pick whatever 639-2 say, after that add anything found in 639-3 not already covered by the first step" could work. > Which source do we mirror, if one says "Waray" and the other > says "Waray (Philippines)"? 639-2. > Which is better for avoiding confusion with "Waray > (Australia)"? 639-3 . Propose a rule how to smuggle Waray (Philippines) into the 639-2 entry. "Comment" is my first idea. Or "let's see how they sort it out" - Peter said that will be done in time. >> ACK. > Bill the Cat? u+0006 in the US-ASCII repertoire :-) > I'm in favor of adding the parenthesized country names > introduced in 639-3, when they serve to distinguish two > languages with otherwise identical names. If it has an obvious pattern we can create a rule for it. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 06:59:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM0YT-0006jB-KK; Sat, 09 Sep 2006 06:59:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM0YR-0006f3-HX for ltru@ietf.org; Sat, 09 Sep 2006 06:59:19 -0400 Received: from mta2.iomartmail.com ([62.128.193.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GM0YQ-0004vL-21 for ltru@ietf.org; Sat, 09 Sep 2006 06:59:19 -0400 Received: from mta2.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta2.iomartmail.com (8.12.8/8.12.8) with ESMTP id k89Ax1U3000307; Sat, 9 Sep 2006 11:59:01 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta2.iomartmail.com (8.12.8/8.12.8) with ESMTP id k89AwuOv032659; Sat, 9 Sep 2006 11:59:01 +0100 Message-Id: <200609091059.k89AwuOv032659@mta2.iomartmail.com> From: "Debbie Garside" To: "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Re: 3066ter encompassed languages Date: Sat, 9 Sep 2006 11:58:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcbT1PVhX6wfNoKMSmWynRI+DJd1UAAKPLQg In-Reply-To: <004601c6d3d4$ec6ea700$6401a8c0@DGBP7M81> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I disagree with this and reiterate my position as stated within the "holy apostrophe debate" on IETF-languages: "all names as represented within the underlying standards should be included in the registry in the EXACT format that they take within the standard. This means that if a name is presented as Foo (Bar) in the underlying standard then it remains as Foo (Bar). Three reasons for this, one: consistency, two: very often the bracketed information acts as an additional qualifier, three: the name can be used by other systems as a Unique Identifier (ISO 11179)." I would further add that human readability should be taken into consideration as should sort order. Thus, in the example given, "Ndebele, North" should be retained. If there is a discrepancy between the descriptions of ISO 639-2 and ISO 639-3 then BOTH should be included IMHO. Best regards Debbie > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: 09 September 2006 06:58 > To: LTRU Working Group > Subject: [Ltru] Re: 3066ter encompassed languages > > Peter Constable wrote: > > > Perhaps we have a working convention that we only use non-inverted > > name forms in the Description field. The inverted forms are useful > > only when providing a sorted list for human-eader lookup, > and that is > > not relevant for the description fields. > > I like this, but can we go one step further for consistency, > and actually *remove* the existing inverted forms for any > subtags that also have the non-inverted form? > > Type: language > Subtag: nd > Description: Ndebele, North <-- remove > Description: North Ndebele > Added: 2005-10-16 > Suppress-Script: Latn > > Type: language > Subtag: nds > Description: Low German > Description: Low Saxon > Description: German, Low <-- remove > Description: Saxon, Low <-- remove > Added: 2005-10-16 > > I don't see anything in Section 3.4 that prohibits this. > Note that I don't propose "un-inverting" any descriptions > when the inverted form is all we have: > > Type: language > Subtag: fro > Description: French, Old (842-ca. 1400) <-- no change > Added: 2005-10-16 > > >> Scenario: We have "Marshallese" and 639-3 changes this to > "Marshall" > >> for no immediately obvious reason. I assume we add it; first or > >> last? > > > > I believe work is being done to fix such minor inconsistencies. > > I know the answer to this already, but it would be nice to > know what things like this (and "zza" as macrolanguage) will > be changed before the final release of 639-3. We can always > plan as if there will be no surprises, and react to those that occur. > > >> Scenario: We have "Luxembourgish" followed by "Letzeburgesch". > >> 639-3 reverses the order. I know many have said order doesn't > >> matter, and I suspect we will do nothing here > > > > Indeed, order doesn't matter. > > Pretty much everyone seems to agree here. > > >> And we may need to decide what to do about "sgn-BE-fr" and > other sign > >> languages that Michael mentions on his page but that > aren't in 639-3. > > > > Someone should prepare proposals to get them added to 639-3; in the > > mean time, those tags remain grandfathered until such time > as there is > > a syntax-conformant tag that can supersede it. > > Agreed. For 4646bis this means we do nothing for "sgn-BE-fr" > and "sgn-BE-nl". John observed that "sgn-CH-de" can be > replaced by "sgn-sgg". > > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > RFC 4645 . UTN #14 > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 07:08:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM0hP-0001WY-6C; Sat, 09 Sep 2006 07:08:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM0hO-0001WT-3q for ltru@ietf.org; Sat, 09 Sep 2006 07:08:34 -0400 Received: from pne-smtpout1-sn1.fre.skanova.net ([81.228.11.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GM0hM-00067m-5I for ltru@ietf.org; Sat, 09 Sep 2006 07:08:33 -0400 Received: from chalmers95a69n (83.248.26.72) by pne-smtpout1-sn1.fre.skanova.net (7.2.076) id 45011B7B00047858 for ltru@ietf.org; Sat, 9 Sep 2006 13:08:28 +0200 From: "Kent Karlsson" To: "'LTRU Working Group'" Subject: RE: [Ltru] Re: 3066ter encompassed languages Date: Sat, 9 Sep 2006 13:07:51 +0200 Message-ID: <001401c6d400$31395fd0$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <004101c6d3d3$283f38f0$6401a8c0@DGBP7M81> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > >> Scenario: We have "Malay". 639-3 changes this to "Malay > (specific)" > > (this was an error, should have been "Malay (generic)") > > >> because there is also "Malay (specific)" plus a host of > others such > >> as "Malay, Ambonese". > > > > If we can also get away with keeping the 639-2 Malay as > is... adding a > > comment with the more specific name is an option. > > My opinion is that that will add a lot of confusion and obfuscate the > relationship between "generic" Malay and its flavors. The following is not really an issue for ltru, nor ietf-languages, but for 639-3. I'm not too keen on the "(specific)" and "(generic)" parts of those descriptions. We already have 'tai': Tai [languages] (other), and 'th'/'tha': Thai. That is an almost parallel case. Almost because of 1) the "other", and 2) the slightly different spelling th/t. But apart from that, and given that (almost) parallel, I think that "Malay (generic)" would be better described as "Malay languages" and "Malay (specific)" would be better described as just "Malay", or even better use one or more of the alternate names given in the Ethnologue, like Standard Malay or Bahasa Malayu. I find that the 639-3 website does not give a list of languages for 'tai', but it does so for "msa". Why that is so? 'tai' should encompass all the Tai languages except Thai and Lao, due to the "other" (it is only "other" w.r.t. 639-2, not w.r.t. 639-3). /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 11:53:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM59B-0003ST-O2; Sat, 09 Sep 2006 11:53:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM59A-0003SO-KP for ltru@ietf.org; Sat, 09 Sep 2006 11:53:32 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GM598-0006EO-DE for ltru@ietf.org; Sat, 09 Sep 2006 11:53:32 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GM597-0007gf-6h; Sat, 09 Sep 2006 11:53:29 -0400 Date: Sat, 9 Sep 2006 11:53:29 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: 3066ter encompassed languages Message-ID: <20060909155329.GL22017@ccil.org> References: <004101c6d3d3$283f38f0$6401a8c0@DGBP7M81> <450294B2.5319@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450294B2.5319@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > But if 639-anything is guaranteed to be unique we don't need the > extlang construct at all. The purpose of extlangs is not for uniqueness (639-anything code elements *are* guaranteed unique) but backward compatibility and ease in matching. For example, 639-1 (and a fortiori 4646) has "ar", meaning simply "Arabic", a term encompassing some 30 distinct languages. Rather than requiring people in search of any sort of Arabic to search for 30 distinct tags, or requiring matchers to keep a table mapping "ar" to all those tags, we instead require taggers specifying (say) Algerian Arabic to use "ar-aao" instead of just "aao". That way, searches for "ar" will automatically match. We have done this for Chinese already, and we attempted to do it for Norwegian as well, but in the latter case (as well as for Serbo-Croatian), ISO 639-1/RA took things out of our hands by creating separate code elements. So people just have to know that "no" encompasses "nb" and "nn" and that "sh" encompasses "sr", "hr", and "bs". We want to avoid having to deal with any more such tacit knowledge. -- Dream projects long deferred John Cowan usually bite the wax tadpole. http://www.ccil.org/~cowan --James Lileks _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 12:52:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM64C-0002JI-3r; Sat, 09 Sep 2006 12:52:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM64B-0002JD-2u for ltru@ietf.org; Sat, 09 Sep 2006 12:52:27 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GM647-0007rm-Gu for ltru@ietf.org; Sat, 09 Sep 2006 12:52:27 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GM646-0000eV-Ic; Sat, 09 Sep 2006 12:52:22 -0400 Date: Sat, 9 Sep 2006 12:52:22 -0400 To: Kent Karlsson Subject: Re: [Ltru] Re: 3066ter encompassed languages Message-ID: <20060909165222.GA31427@ccil.org> References: <004101c6d3d3$283f38f0$6401a8c0@DGBP7M81> <001401c6d400$31395fd0$6500a8c0@chalmers95a69n> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001401c6d400$31395fd0$6500a8c0@chalmers95a69n> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson scripsit: > We already have 'tai': Tai [languages] (other), and 'th'/'tha': Thai. That > is an almost parallel case. Almost because of 1) the "other", and > 2) the slightly different spelling th/t. Unfortunately, that spelling difference is fundamental. The difference between "th" and "t" (aspirated vs. not aspirated) is not very apparent to Germanic-speaking ears; it is the difference between the /t/ in English "tie" (which is pronounced like "Thai") and English "sty" (which, if you excised the /s/ sound, would sound like "Tai"). Furthermore, "Tai" is the name of a genetic subtree of languages, whereas "Thai" is the name of a specific language. More on that below. > I find that the 639-3 website does not give a list of languages for > 'tai', but it does so for "msa". Why that is so? 'tai' should encompass > all the Tai languages except Thai and Lao, due to the "other" (it is > only "other" w.r.t. 639-2, not w.r.t. 639-3). That requires some explanation. In ISO 639-2, there are two kinds of code elements; those for individual languages such as "eng" and those for language collectives such as "tai" or "nai" (North American languages). The intention was to provide *some* code element for every language, even if not a unique one. Thus documents in all Tai languages other than Thai and Lao could be tagged "tai". However, this was unstable, because if an additional Tai language were registered by 639-2/RA, the denotation of "tai" would technically change to exclude it, possibly invalidating existing data. Furthermore, the definition of a Tai language is dependent on scholarship, and may change over time to include more or fewer languages. 639-3 is a registry of individual languages only, and does not include any collective language tags -- ISO 639-5 will contain a selection of such tags, including all those in 639-2, and ISO 639-6 will contain more. However, it was found that in many cases individual 639-2 languages mapped to more than one 639-3 language. These 639-2 languages were therefore added to 639-3 as macrolanguages, with explicit and permanent mappings to the corresponding 639-3 individual languages. It is these mappings that we will use to establish which 639-3 individual languages will be registered as language subtags and which as extlang subtags. -- As we all know, civil libertarians are not John Cowan the friskiest group around -- comes from cowan@ccil.org forever being on the qui vive for the sound http://www.ccil.org/~cowan of jack-booted fascism coming down the pike. --Molly Ivins _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 12:53:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM651-0002Rm-EV; Sat, 09 Sep 2006 12:53:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM64z-0002Rh-DK for ltru@ietf.org; Sat, 09 Sep 2006 12:53:17 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GM64x-0007xk-23 for ltru@ietf.org; Sat, 09 Sep 2006 12:53:17 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 480531E1618; Sat, 9 Sep 2006 09:53:10 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 9 Sep 2006 09:53:10 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EEF0@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'John Cowan' , Randy Presuhn Subject: RE: [Ltru] RFC 4646!! [posted by RFC Editor] Date: Sat, 9 Sep 2006 09:53:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, As of today (Saturday 9 September 2006), are posted at: ftp://ftp.isi.edu/in-notes RFC 4645 is 7 pages long (i.e., does NOT contain the initial registry contents). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: Friday, September 08, 2006 4:20 PM > To: Randy Presuhn > Cc: ltru@ietf.org > Subject: Re: [Ltru] RFC 4646!! > > > Randy Presuhn scripsit: > > > Uh - when did the announcement go out? I haven't seen it. > > I haven't even seen the note from the rfc-editor announcing > > their intent to make it available. > > See http://www.rfc-editor.org/new_rfcs.html . I don't know > whether this page is authoritative or not. > > I also note, belatedly, that it assigns RFC 4645 to the > Doug's initial registry -- hopefully only the prose bits, > not the record-jar portion. > > The three links to RFC 464[567] are broken. > > -- > John Cowan http://www.ccil.org/~cowan > Raffiniert ist der Herrgott, aber boshaft ist er nicht. > --Albert Einstein > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.2/442 - Release Date: 9/8/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 13:39:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM6ng-0003TG-FK; Sat, 09 Sep 2006 13:39:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM6ne-0003TB-Qe for ltru@ietf.org; Sat, 09 Sep 2006 13:39:26 -0400 Received: from pne-smtpout2-sn1.fre.skanova.net ([81.228.11.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GM6nd-0002j7-FL for ltru@ietf.org; Sat, 09 Sep 2006 13:39:26 -0400 Received: from chalmers95a69n (83.248.26.72) by pne-smtpout2-sn1.fre.skanova.net (7.2.075) id 44FEC7CA000E4A56; Sat, 9 Sep 2006 19:39:12 +0200 From: "Kent Karlsson" To: "'John Cowan'" Subject: RE: [Ltru] Re: 3066ter encompassed languages Date: Sat, 9 Sep 2006 19:38:33 +0200 Message-ID: <001701c6d436$c6359280$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20060909165222.GA31427@ccil.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Kent Karlsson scripsit: > > > We already have 'tai': Tai [languages] (other), and > 'th'/'tha': Thai. That > > is an almost parallel case. Almost because of 1) the "other", and > > 2) the slightly different spelling th/t. > > Unfortunately, that spelling difference is fundamental. The > difference > between "th" and "t" (aspirated vs. not aspirated) is not > very apparent to > Germanic-speaking ears; it is the difference between the /t/ > in English > "tie" (which is pronounced like "Thai") and English "sty" (which, if > you excised the /s/ sound, would sound like "Tai"). > > Furthermore, "Tai" is the name of a genetic subtree of > languages, whereas > "Thai" is the name of a specific language. More on that below. Let me try again, since you managed to completely miss my point: I think it would be much better (for 639-3) to have descriptions like msa: Malay languages mly: Standard Malay, Bahasa Malayu or even msa: Malay languages mly: Malay rather than the very artificial msa: Malay (generic) mly: Malay (specific) > > I find that the 639-3 website does not give a list of languages for > > 'tai', but it does so for "msa". Why that is so? 'tai' > should encompass > > all the Tai languages except Thai and Lao, due to the "other" (it is > > only "other" w.r.t. 639-2, not w.r.t. 639-3). > > That requires some explanation. In ISO 639-2, there are two kinds of > code elements; those for individual languages such as "eng" > and those for > language collectives such as "tai" or "nai" (North American > languages). > > The intention was to provide *some* code element for every language, > even if not a unique one. Thus documents in all Tai languages other > than Thai and Lao could be tagged "tai". However, this was unstable, > because if an additional Tai language were registered by 639-2/RA, > the denotation of "tai" would technically change to exclude > it, possibly > invalidating existing data. Furthermore, the definition of a > Tai language > is dependent on scholarship, and may change over time to include more > or fewer languages. > > 639-3 is a registry of individual languages only, and does not include > any collective language tags -- ISO 639-5 will contain a selection of > such tags, including all those in 639-2, and ISO 639-6 will > contain more. > However, it was found that in many cases individual 639-2 > languages mapped > to more than one 639-3 language. These 639-2 languages were therefore > added to 639-3 as macrolanguages, with explicit and permanent mappings > to the corresponding 639-3 individual languages. > > It is these mappings that we will use to establish which > 639-3 individual > languages will be registered as language subtags and which as extlang > subtags. But the IANA LSTR will not the same as 639-3 (for language codes). The IANA LSTR will, for stability reasons, continue to contain "collective" codes. We could either: 1) deprecate them ("collective" codes) all and for each of them refer to individual language codes (from 639-3 but not in 639-2), or 2) leave them as additional "macrolanguages", giving individual language codes (from 639-3, not any in 639-2) as "extlangs" for each. Either way, we would need an authoritative list of the individual language codes each of them *currently* cover (not to be updated in future versions, for stability, even if would leave the lists as outdated). I don't think it would be a good idea to leave them as is. I would prefer alternative 1 above, but some of them may have been used (despite that being a bad idea), in which case alternative 2 may be better. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 13:57:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM74p-0002Op-2c; Sat, 09 Sep 2006 13:57:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM74o-0002Ok-PZ for ltru@ietf.org; Sat, 09 Sep 2006 13:57:10 -0400 Received: from mta6.iomartmail.com ([62.128.193.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GM74n-00056A-9U for ltru@ietf.org; Sat, 09 Sep 2006 13:57:10 -0400 Received: from mta6.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k89Humn4025963; Sat, 9 Sep 2006 18:56:48 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k89Huh5U025917; Sat, 9 Sep 2006 18:56:47 +0100 Message-Id: <200609091756.k89Huh5U025917@mta6.iomartmail.com> From: "Debbie Garside" To: "'Kent Karlsson'" , "'John Cowan'" Subject: RE: [Ltru] Re: 3066ter encompassed languages Date: Sat, 9 Sep 2006 18:56:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcbUNvMwd5tiYGZ3SWivF1Gz35JQwQAAcN0Q In-Reply-To: <001701c6d436$c6359280$6500a8c0@chalmers95a69n> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent wrote: > I think it would be much better (for 639-3) to have descriptions like > > msa: Malay languages > mly: Standard Malay, Bahasa Malayu > > or even > > msa: Malay languages > mly: Malay > > rather than the very artificial > > msa: Malay (generic) > mly: Malay (specific) In which case please suggest it to the ISO 639 JAC. To reiterate, the Registry should reflect the standards exactly. Alternatively, suggest an additional description but always include the description as per the underlying standard. Best regards Debbie Garside > -----Original Message----- > From: Kent Karlsson [mailto:kent.karlsson14@comhem.se] > Sent: 09 September 2006 18:39 > To: 'John Cowan' > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: 3066ter encompassed languages > > John Cowan wrote: > > Kent Karlsson scripsit: > > > > > We already have 'tai': Tai [languages] (other), and > > 'th'/'tha': Thai. That > > > is an almost parallel case. Almost because of 1) the "other", and > > > 2) the slightly different spelling th/t. > > > > Unfortunately, that spelling difference is fundamental. The > > difference between "th" and "t" (aspirated vs. not > aspirated) is not > > very apparent to Germanic-speaking ears; it is the > difference between > > the /t/ in English "tie" (which is pronounced like "Thai") > and English > > "sty" (which, if you excised the /s/ sound, would sound like "Tai"). > > > > Furthermore, "Tai" is the name of a genetic subtree of languages, > > whereas "Thai" is the name of a specific language. More on that > > below. > > Let me try again, since you managed to completely miss my point: > > I think it would be much better (for 639-3) to have descriptions like > > msa: Malay languages > mly: Standard Malay, Bahasa Malayu > > or even > > msa: Malay languages > mly: Malay > > rather than the very artificial > > msa: Malay (generic) > mly: Malay (specific) > > > > I find that the 639-3 website does not give a list of > languages for > > > 'tai', but it does so for "msa". Why that is so? 'tai' > > should encompass > > > all the Tai languages except Thai and Lao, due to the > "other" (it is > > > only "other" w.r.t. 639-2, not w.r.t. 639-3). > > > > That requires some explanation. In ISO 639-2, there are > two kinds of > > code elements; those for individual languages such as "eng" > > and those for > > language collectives such as "tai" or "nai" (North American > > languages). > > > > The intention was to provide *some* code element for every > language, > > even if not a unique one. Thus documents in all Tai > languages other > > than Thai and Lao could be tagged "tai". However, this was > unstable, > > because if an additional Tai language were registered by > 639-2/RA, the > > denotation of "tai" would technically change to exclude it, > possibly > > invalidating existing data. Furthermore, the definition of a Tai > > language is dependent on scholarship, and may change over time to > > include more or fewer languages. > > > > 639-3 is a registry of individual languages only, and does > not include > > any collective language tags -- ISO 639-5 will contain a > selection of > > such tags, including all those in 639-2, and ISO 639-6 will contain > > more. > > However, it was found that in many cases individual 639-2 languages > > mapped to more than one 639-3 language. These 639-2 languages were > > therefore added to 639-3 as macrolanguages, with explicit and > > permanent mappings to the corresponding 639-3 individual languages. > > > > It is these mappings that we will use to establish which > > 639-3 individual > > languages will be registered as language subtags and which > as extlang > > subtags. > > But the IANA LSTR will not the same as 639-3 (for language codes). > The IANA LSTR will, for stability reasons, continue to > contain "collective" codes. We could either: > > 1) deprecate them ("collective" codes) all and for each of > them refer to individual language codes (from 639-3 but not > in 639-2), or > > 2) leave them as additional "macrolanguages", giving > individual language codes (from 639-3, not any in 639-2) as > "extlangs" for each. > > Either way, we would need an authoritative list of the > individual language codes each of them *currently* cover (not > to be updated in future versions, for stability, even if > would leave the lists as outdated). > > I don't think it would be a good idea to leave them as is. I > would prefer alternative 1 above, but some of them may have > been used (despite that being a bad idea), in which case > alternative 2 may be better. > > /kent k > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 15:39:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM8g6-00005z-2K; Sat, 09 Sep 2006 15:39:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM8g3-00005r-Vn for ltru@ietf.org; Sat, 09 Sep 2006 15:39:43 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GM8g2-0005hQ-Od for ltru@ietf.org; Sat, 09 Sep 2006 15:39:43 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GM8g1-0004er-Ur; Sat, 09 Sep 2006 15:39:41 -0400 Date: Sat, 9 Sep 2006 15:39:41 -0400 To: Kent Karlsson Subject: Re: [Ltru] Re: 3066ter encompassed languages Message-ID: <20060909193941.GA17458@ccil.org> References: <20060909165222.GA31427@ccil.org> <001701c6d436$c6359280$6500a8c0@chalmers95a69n> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001701c6d436$c6359280$6500a8c0@chalmers95a69n> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson scripsit: > I think it would be much better (for 639-3) to have descriptions like > > msa: Malay languages > mly: Standard Malay, Bahasa Malayu > > or even > > msa: Malay languages > mly: Malay That would be misleading. "languages" suggests a collection of languages, whereas msa is a macrolanguage. Understanding this distinction is fundamental. > rather than the very artificial > > msa: Malay (generic) > mly: Malay (specific) It's an artificial situation caused by a mismatch between 639-2 and -3. > But the IANA LSTR will not the same as 639-3 (for language codes). > The IANA LSTR will, for stability reasons, continue to contain > "collective" codes. We could either: > > 1) deprecate them ("collective" codes) all and for each of them refer to > individual language codes (from 639-3 but not in 639-2), or That would be IMHO overkill. Sometimes you simply don't know, or need to know, the specific language of a document. I would not object to a new "discouraged" status intermediate between deprecated and encouraged. > 2) leave them as additional "macrolanguages", giving individual language > codes (from 639-3, not any in 639-2) as "extlangs" for each. > > Either way, we would need an authoritative list of the individual > language codes each of them *currently* cover (not to be updated > in future versions, for stability, even if would leave the lists > as outdated). No such lists exist or are likely to exist; there is not even scholarly agreement on their contents in many cases. -- But that, he realized, was a foolish John Cowan thought; as no one knew better than he cowan@ccil.org that the Wall had no other side. http://www.ccil.org/~cowan --Arthur C. Clarke, "The Wall of Darkness" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 19:18:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMC5J-00022X-R5; Sat, 09 Sep 2006 19:18:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMC5J-00021t-70 for ltru@ietf.org; Sat, 09 Sep 2006 19:18:01 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMC5G-00058e-SQ for ltru@ietf.org; Sat, 09 Sep 2006 19:18:01 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bOS63YG2rzLOGZSiD+ctXWRh2UbRE4HlfFVkB7+L0BwfbSEz+3vrZNW7qp0M8bXI; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.188.149] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GMC5F-0002RA-Qc for ltru@ietf.org; Sat, 09 Sep 2006 19:17:58 -0400 Message-ID: <001201c6d466$9c88c6c0$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <005601c6d3d8$417c7530$6401a8c0@DGBP7M81> Subject: Re: [Ltru] Re: Fw: RFC 4645 on Initial Language Subtag Registry Date: Sat, 9 Sep 2006 16:20:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7af2a1ea041b2226cdedcad372f90ba6301350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.149 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Friday, September 08, 2006 11:21 PM > Subject: [Ltru] Re: Fw: RFC 4645 on Initial Language Subtag Registry ... > I still think we should investigate whether a new, huge RFC that will be > chopped down to 7 pages before publication is the best way to deliver > the new 4646bis data to IANA. ... As a technical contributor - Based on how the last round went, I think the WG's decision to use an internet draft was correct. I think the WG's decision to publish to send that material through the RFC publication process was also good, inasmuch as it did elicit useful comments, and gave us the requisite paper trail to deal with real or imagined procedural problems. I think the final decision to elide the interesting parts was perhaps unfortunate, but also understandable, given the onslaught the IETF has been suffering. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 19:32:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMCJd-0007p1-AR; Sat, 09 Sep 2006 19:32:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMCJb-0007ls-Sm for ltru@ietf.org; Sat, 09 Sep 2006 19:32:48 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMCJa-0007kh-KK for ltru@ietf.org; Sat, 09 Sep 2006 19:32:47 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=S0aQ4D1X/IsBmWpG8a2ASn9v0gW7ENam1E2Gkxz47/VorWZFJqSbe3+uvJI18kBE; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.188.149] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GMCJZ-0001kO-U6 for ltru@ietf.org; Sat, 09 Sep 2006 19:32:46 -0400 Message-ID: <004001c6d468$b6fa92c0$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "'LTRU Working Group'" References: <200609091059.k89AwuOv032659@mta2.iomartmail.com> Subject: Re: [Ltru] Re: 3066ter encompassed languages Date: Sat, 9 Sep 2006 16:36:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7afe6180e8498e4ef0643b25bed7507f74c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.149 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Debbie Garside" > To: "'Doug Ewell'" ; "'LTRU Working Group'" > Sent: Saturday, September 09, 2006 3:58 AM > Subject: RE: [Ltru] Re: 3066ter encompassed languages > > I disagree with this and reiterate my position as stated within the "holy > apostrophe debate" on IETF-languages: > > "all names as represented within the underlying standards should be included > in the registry in the EXACT format that they take within the standard. > This means that if a name is presented as Foo (Bar) in the underlying > standard then it remains as Foo (Bar). Three reasons for this, one: > consistency, two: very often the bracketed information acts as an additional > qualifier, three: the name can be used by other systems as a Unique > Identifier (ISO 11179)." > > I would further add that human readability should be taken into > consideration as should sort order. Thus, in the example given, "Ndebele, > North" should be retained. > > If there is a discrepancy between the descriptions of ISO 639-2 and ISO > 639-3 then BOTH should be included IMHO. ... As a technical contributor, and in the context of the work of the ltru WG, I agree whole-heartedly. Anything other than what can be extracted algorithmicly from the base standards should be debated on a case-by-case basis on the ietf-languages@iana.org list. Our work here is not to "improve" upon the raw data. It is to ensure that the registry format and procedures support the needs of language tagging, and, incidentally, to supply "mass initialization" data *derived* from those base standards. We aren't here to editorialize or improve on that data. That's a problem for the ietf-languages@iana.org list. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 19:41:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMCSM-0002vY-Ip; Sat, 09 Sep 2006 19:41:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMCSL-0002sH-9W for ltru@ietf.org; Sat, 09 Sep 2006 19:41:49 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMCSK-0000x9-2C for ltru@ietf.org; Sat, 09 Sep 2006 19:41:49 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=DSGgbwqzeznVVpTQGM4zXB2UXTVEA5AXyeOgrki3llgZtIvDU/Q7ThJ5xNWkRIx4; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.188.149] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GMCSJ-00065G-Bf for ltru@ietf.org; Sat, 09 Sep 2006 19:41:47 -0400 Message-ID: <004901c6d469$f9d861c0$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <005401c6d3d7$9d2c66c0$6401a8c0@DGBP7M81> Subject: Re: [Ltru] Re: prefixes for date variants Date: Sat, 9 Sep 2006 16:45:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7affac8a03431282a8be483cd5fe38454c1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.149 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Friday, September 08, 2006 11:17 PM > Subject: [Ltru] Re: prefixes for date variants ... > Having an up-to-date > copy of the Registry is something that should be encouraged. ... As a technical contributor, I believe this would be a grave mistake, unless we *severely* qualify what is meant by "user." I believe that vast majority of users have no need whatsoever for language tag validators. Normal users should never even see language tags, much less be creating them. Language tags used in protocol should be put there by software as a result of other user choices. I think the only folks who should be using tag validators are the developers of applications which generate language tags. These are hardly typical "users". Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 09 21:14:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMDu4-0005uu-2B; Sat, 09 Sep 2006 21:14:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMDu3-0005un-0V for ltru@ietf.org; Sat, 09 Sep 2006 21:14:31 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMDu1-0007KJ-PS for ltru@ietf.org; Sat, 09 Sep 2006 21:14:30 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GMDu1-0006KP-EL for ltru@ietf.org; Sat, 09 Sep 2006 21:14:29 -0400 Date: Sat, 9 Sep 2006 21:14:29 -0400 To: ltru@ietf.org Message-ID: <20060910011429.GA12746@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Ltru] Up-to-date copies of the LSR X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > > Having an up-to-date > > copy of the Registry is something that should be encouraged. > > As a technical contributor, I believe this would be a grave mistake, > unless we *severely* qualify what is meant by "user." I believe > that vast majority of users have no need whatsoever for language > tag validators. Normal users should never even see language tags, > much less be creating them. Language tags used in protocol should be > put there by software as a result of other user choices. I think the > only folks who should be using tag validators are the developers of > applications which generate language tags. These are hardly typical > "users". I don't think it's so simple. I've been talking with Eric Muller of uhdrinunicode.org, who's developing Unicode plain-text versions of the Universal Declaration of Human Rights in a large variety of languages. Currently he uses Ethnologue tags, and he's asked me whether a RFC4646bis prototype evaluator is available so he can look into converting to that standard when it becomes available. (Doug?) Apache, to take another example, can do language negotation if appropriately configured, so that if you ask for foo.html in French, you get foo.html.fr, whereas if you ask for foo.html in English, you get foo.html.en. The people who create those files, if they do so by hand, need to use language tags. I think Doug means not that people should be encouraged to pull the LSR dynamically, but rather that programs that encapsulate the state of the LSR (like his Windows version) should be made widely available and updated fairly regularly, monthly or every two months or whatever. -- You let them out again, Old Man Willow! John Cowan What you be a-thinking of? You should not be waking! cowan@ccil.org Eat earth! Dig deep! Drink water! Go to sleep! Bombadil is talking. http://ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 00:58:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMHOj-0005zR-0w; Sun, 10 Sep 2006 00:58:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMHOh-0005zG-Am for ltru@ietf.org; Sun, 10 Sep 2006 00:58:23 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMHOd-00041u-VM for ltru@ietf.org; Sun, 10 Sep 2006 00:58:23 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Sat, 9 Sep 2006 21:58:19 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Sat, 9 Sep 2006 21:58:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: 3066ter encompassed languages Date: Sat, 9 Sep 2006 21:57:45 -0700 Message-ID: In-Reply-To: <001701c6d436$c6359280$6500a8c0@chalmers95a69n> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: 3066ter encompassed languages thread-index: AcbUNvPLaIr+w+2ZQGKHDghz8ArUwAAVeVRg References: <20060909165222.GA31427@ccil.org> <001701c6d436$c6359280$6500a8c0@chalmers95a69n> From: Peter Constable To: X-OriginalArrivalTime: 10 Sep 2006 04:58:12.0557 (UTC) FILETIME=[B7CDC7D0:01C6D495] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Kent Karlsson [mailto:kent.karlsson14@comhem.se]=20 > Let me try again, since you managed to completely miss my point: > > I think it would be much better (for 639-3) to have descriptions like > msa: Malay languages > mly: Standard Malay, Bahasa Malayu > > or even > > msa: Malay languages > mly: Malay > >rather than the very artificial > > msa: Malay (generic) > mly: Malay (specific) No, you have missed the point. In ISO 639, entries with names of the form "... languages" are *collections*. The entry with the ID msa is *not* a collection; it is a macrolanguage.=20 It is listed in ISO 639-2 as an individual language, "Malay", and as such has usage as though it denoted a single language. But in ISO 639-3 there are several individual languages that (possibly -- more below) are encompassed by msa. One of these is the language Malay, also known as Bahasa Malaysia or Standard Malay, which has its own ID mly. In order to keep unique reference names for every entry, 639-3 needs some way to distinguish "Malay" in the case of msa from "Malay" in the case of mly. When preparing the draft code table for 639-3, most cases of macrolanguages did not have a problem with the reference name being identical to the reference name of some individual language, but there were a few, one of which was Malay. Now, a few comments are needed here: - You are looking at a *draft* table for 639-3. - One of the open issues that the JAC needs to make a decision on is how the 639-2 entry should be treated in relation to entries in 639-3: is it equated with mly (in which case mly would be removed from the code table), or is it treated as a macrolanguage (as reflected in the draft code table)?=20 - If the JFrom ltru-bounces@ietf.org Sun Sep 10 00:58:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMHOj-0005zR-0w; Sun, 10 Sep 2006 00:58:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMHOh-0005zG-Am for ltru@ietf.org; Sun, 10 Sep 2006 00:58:23 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMHOd-00041u-VM for ltru@ietf.org; Sun, 10 Sep 2006 00:58:23 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Sat, 9 Sep 2006 21:58:19 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Sat, 9 Sep 2006 21:58:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: 3066ter encompassed languages Date: Sat, 9 Sep 2006 21:57:45 -0700 Message-ID: In-Reply-To: <001701c6d436$c6359280$6500a8c0@chalmers95a69n> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: 3066ter encompassed languages thread-index: AcbUNvPLaIr+w+2ZQGKHDghz8ArUwAAVeVRg References: <20060909165222.GA31427@ccil.org> <001701c6d436$c6359280$6500a8c0@chalmers95a69n> From: Peter Constable To: X-OriginalArrivalTime: 10 Sep 2006 04:58:12.0557 (UTC) FILETIME=[B7CDC7D0:01C6D495] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Kent Karlsson [mailto:kent.karlsson14@comhem.se]=20 > Let me try again, since you managed to completely miss my point: > > I think it would be much better (for 639-3) to have descriptions like > msa: Malay languages > mly: Standard Malay, Bahasa Malayu > > or even > > msa: Malay languages > mly: Malay > >rather than the very artificial > > msa: Malay (generic) > mly: Malay (specific) No, you have missed the point. In ISO 639, entries with names of the form "... languages" are *collections*. The entry with the ID msa is *not* a collection; it is a macrolanguage.=20 It is listed in ISO 639-2 as an individual language, "Malay", and as such has usage as though it denoted a single language. But in ISO 639-3 there are several individual languages that (possibly -- more below) are encompassed by msa. One of these is the language Malay, also known as Bahasa Malaysia or Standard Malay, which has its own ID mly. In order to keep unique reference names for every entry, 639-3 needs some way to distinguish "Malay" in the case of msa from "Malay" in the case of mly. When preparing the draft code table for 639-3, most cases of macrolanguages did not have a problem with the reference name being identical to the reference name of some individual language, but there were a few, one of which was Malay. Now, a few comments are needed here: - You are looking at a *draft* table for 639-3. - One of the open issues that the JAC needs to make a decision on is how the 639-2 entry should be treated in relation to entries in 639-3: is it equated with mly (in which case mly would be removed from the code table), or is it treated as a macrolanguage (as reflected in the draft code table)?=20 - If the JAC decides to treat msa as identical to mly resulting in the separate entry mly being deleted, then there is no longer an issue with two entries having otherwise identical reference names. - If the JAC decides to treat msa as a macrolanguage, then there is still opportunity for the reference names to be revised, and the problem might perhaps be avoidable (e.g. by using "Standard Malay" or "Bahasa Malay" for mly). > But the IANA LSTR will not the same as 639-3 (for language codes). > The IANA LSTR will, for stability reasons, continue to contain > "collective" codes. We could either: > > 1) deprecate them ("collective" codes) all and for each of them refer to > individual language codes (from 639-3 but not in 639-2), or I've always been in favour of deprecating collective IDs from use in IETF language tags.=20 > 2) leave them as additional "macrolanguages", giving individual language > codes (from 639-3, not any in 639-2) as "extlangs" for each. Absolutely not! > Either way, we would need an authoritative list of the individual > language > codes each of them *currently* cover (not to be updated in future > versions, > for stability, even if would leave the lists as outdated). That was not done as part of 639-3 because it was out of scope; it might be in scope for 639-5, however. In the early work on 639-3, when Gary Simons and I were preparing proposals for ISO, we did our initial analysis of the relationship between ISO 639-2 and Ethnologue 14th edition. That included mappings from collections in 639-2 to individual languages, and that is available here: http://www.ethnologue.com/14/iso639/analysis.asp#C > I don't think it would be a good idea to leave them as is. I would > prefer > alternative 1 above, but some of them may have been used (despite that > being a bad idea), in which case alternative 2 may be better. I think alternative 2 is worse than any existing use of a collective ID. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 00:58:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMHOk-0005zV-3j; Sun, 10 Sep 2006 00:58:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMHOi-0005zM-MY for ltru@ietf.org; Sun, 10 Sep 2006 00:58:24 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMHOh-00041u-ET for ltru@ietf.org; Sun, 10 Sep 2006 00:58:24 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Sat, 9 Sep 2006 21:58:19 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Sat, 9 Sep 2006 21:58:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: 3066ter encompassed languages Date: Sat, 9 Sep 2006 21:57:46 -0700 Message-ID: In-Reply-To: <004001c6d468$b6fa92c0$6501a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: 3066ter encompassed languages thread-index: AcbUaE7PqfpImlazQ5WaC028JvNJDwAK+z4w References: <200609091059.k89AwuOv032659@mta2.iomartmail.com> <004001c6d468$b6fa92c0$6501a8c0@oemcomputer> From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 10 Sep 2006 04:58:12.0807 (UTC) FILETIME=[B7F3ED70:01C6D495] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-UnsuAC decides to treat msa as identical to mly resulting in the separate entry mly being deleted, then there is no longer an issue with two entries having otherwise identical reference names. - If the JAC decides to treat msa as a macrolanguage, then there is still opportunity for the reference names to be revised, and the problem might perhaps be avoidable (e.g. by using "Standard Malay" or "Bahasa Malay" for mly). > But the IANA LSTR will not the same as 639-3 (for language codes). > The IANA LSTR will, for stability reasons, continue to contain > "collective" codes. We could either: > > 1) deprecate them ("collective" codes) all and for each of them refer to > individual language codes (from 639-3 but not in 639-2), or I've always been in favour of deprecating collective IDs from use in IETF language tags.=20 > 2) leave them as additional "macrolanguages", giving individual language > codes (from 639-3, not any in 639-2) as "extlangs" for each. Absolutely not! > Either way, we would need an authoritative list of the individual > language > codes each of them *currently* cover (not to be updated in future > versions, > for stability, even if would leave the lists as outdated). That was not done as part of 639-3 because it was out of scope; it might be in scope for 639-5, however. In the early work on 639-3, when Gary Simons and I were preparing proposals for ISO, we did our initial analysis of the relationship between ISO 639-2 and Ethnologue 14th edition. That included mappings from collections in 639-2 to individual languages, and that is available here: http://www.ethnologue.com/14/iso639/analysis.asp#C > I don't think it would be a good idea to leave them as is. I would > prefer > alternative 1 above, but some of them may have been used (despite that > being a bad idea), in which case alternative 2 may be better. I think alternative 2 is worse than any existing use of a collective ID. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 00:58:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMHOk-0005zV-3j; Sun, 10 Sep 2006 00:58:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMHOi-0005zM-MY for ltru@ietf.org; Sun, 10 Sep 2006 00:58:24 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMHOh-00041u-ET for ltru@ietf.org; Sun, 10 Sep 2006 00:58:24 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Sat, 9 Sep 2006 21:58:19 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Sat, 9 Sep 2006 21:58:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: 3066ter encompassed languages Date: Sat, 9 Sep 2006 21:57:46 -0700 Message-ID: In-Reply-To: <004001c6d468$b6fa92c0$6501a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: 3066ter encompassed languages thread-index: AcbUaE7PqfpImlazQ5WaC028JvNJDwAK+z4w References: <200609091059.k89AwuOv032659@mta2.iomartmail.com> <004001c6d468$b6fa92c0$6501a8c0@oemcomputer> From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 10 Sep 2006 04:58:12.0807 (UTC) FILETIME=[B7F3ED70:01C6D495] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 > > If there is a discrepancy between the descriptions of ISO 639-2 and ISO > > 639-3 then BOTH should be included IMHO. > > As a technical contributor, and in the context of the work of the ltru WG, > I agree whole-heartedly. Anything other than what can be extracted > algorithmicly from the base standards should be debated on a case-by-case > basis on the ietf-languages@iana.org list. IMO, you might just as appropriately have said this in your role as a WG chair: you're clarifying what is in scope for this WG versus what is in scope for the ietf-languages list. Probably some of us that participate in both forget the distinction; I'm sure I do at times. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru bscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 > > If there is a discrepancy between the descriptions of ISO 639-2 and ISO > > 639-3 then BOTH should be included IMHO. > > As a technical contributor, and in the context of the work of the ltru WG, > I agree whole-heartedly. Anything other than what can be extracted > algorithmicly from the base standards should be debated on a case-by-case > basis on the ietf-languages@iana.org list. IMO, you might just as appropriately have said this in your role as a WG chair: you're clarifying what is in scope for this WG versus what is in scope for the ietf-languages list. Probably some of us that participate in both forget the distinction; I'm sure I do at times. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 12:42:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMSNX-0002n0-6G; Sun, 10 Sep 2006 12:41:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMSNW-0002e9-1v for ltru@lists.ietf.org; Sun, 10 Sep 2006 12:41:54 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMSNU-0007dY-FH for ltru@lists.ietf.org; Sun, 10 Sep 2006 12:41:54 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GMSN4-0007qD-0n for ltru@lists.ietf.org; Sun, 10 Sep 2006 18:41:26 +0200 Received: from du-001-109.access.de.clara.net ([212.82.227.109]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Sep 2006 18:41:26 +0200 Received: from nobody by du-001-109.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Sep 2006 18:41:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 10 Sep 2006 18:40:14 +0200 Organization: Lines: 36 Message-ID: <45043FEE.5B3B@xyzzy.claranet.de> References: <004101c6d3d3$283f38f0$6401a8c0@DGBP7M81> <450294B2.5319@xyzzy.claranet.de> <20060909155329.GL22017@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-109.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ltru] Re: 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > For example, 639-1 (and a fortiori 4646) has "ar", meaning > simply "Arabic", a term encompassing some 30 distinct > languages. Rather than requiring people in search of any > sort of Arabic to search for 30 distinct tags, or requiring > matchers to keep a table mapping "ar" to all those tags, we > instead require taggers specifying (say) Algerian Arabic to > use "ar-aao" instead of just "aao". That way, searches for > "ar" will automatically match. So far okay. And are we sure that this info has to be made explicit in billions of tags instead of once in the registry ? In many cases the tags don't offer this redundancy. If I'm looking for "de" nobody can (based alone on the registry) automatically guess that I can also read "nds". The opposite case is certainly irrelevant, I can't read "ar", let alone "ar-aao". [no] > in the latter case (as well as for Serbo-Croatian), ISO > 639-1/RA took things out of our hands by creating separate > code elements. So people just have to know that "no" > encompasses "nb" and "nn" and that "sh" encompasses "sr", > "hr", and "bs". We want to avoid having to deal with any > more such tacit knowledge. Knowledge is good, inconsistent redundancy is another issue. So far nothing happened, the syntax exists, all new parsers can handle it. Last chance to pull a "Suppress-Macrolanguage" SHOULD in 4646bis (as in SHOULD aao, or SHOULD NOT ar-aao). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 13:22:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMT0q-0001EK-PY; Sun, 10 Sep 2006 13:22:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMT0p-0001ED-DD for ltru@lists.ietf.org; Sun, 10 Sep 2006 13:22:31 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMT0o-0006e7-2x for ltru@lists.ietf.org; Sun, 10 Sep 2006 13:22:31 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GMT0d-000658-5h for ltru@lists.ietf.org; Sun, 10 Sep 2006 19:22:19 +0200 Received: from du-001-109.access.de.clara.net ([212.82.227.109]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Sep 2006 19:22:19 +0200 Received: from nobody by du-001-109.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Sep 2006 19:22:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 10 Sep 2006 19:19:38 +0200 Organization: Lines: 43 Message-ID: <4504492A.51DA@xyzzy.claranet.de> References: <200609091059.k89AwuOv032659@mta2.iomartmail.com> <004001c6d468$b6fa92c0$6501a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-109.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Ltru] Re: 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: >> From: "Debbie Garside" [...] >> If there is a discrepancy between the descriptions of ISO >> 639-2 and ISO 639-3 then BOTH should be included IMHO. [...] > I agree whole-heartedly. Anything other than what can be > extracted algorithmicly from the base standards should be > debated on a case-by-case basis on the > ietf-languages@iana.org list. +1 And as far as I'm concerned if the sources aren't in an ideal state the review list should be limited to comments in the registry, and otherwise accept what it gets. Apparently there's one minor detail here, Debbie proposes to take both decriptions if they're different. My idea was to stick to (only) 639-2 for any languages it cares to list. Debbie's plan is probably better, merge the descriptions if they are different. If that results in "Church, slavic" + "Slavic, church" the registry and readers will survive it - for about 16 conflicts it's no issue, and Peter said that some discrepancies will be worked out in 639-3. > We aren't here to editorialize or improve on that data. +1 > That's a problem for the ietf-languages@iana.org list. The "description" shouldn't be their territory, it should be fixed in the sources. For 4646bis I'd like a statement that we expect all primary and extlang tags to use a unique namespace (apparent "dupes" limited to grandfathered tags). But we cannot guarantee that there's only one non-deprecated subtag for a given (primary or extlang) description. With an example if it exists, maybe "Malay". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 13:45:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMTMb-0000tM-W8; Sun, 10 Sep 2006 13:45:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMTMa-0000tE-8g for ltru@ietf.org; Sun, 10 Sep 2006 13:45:00 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMTMV-0004iY-U5 for ltru@ietf.org; Sun, 10 Sep 2006 13:45:00 -0400 Received: from [10.72.76.233] (snvvpn2-10-72-76-c233.corp.yahoo.com [10.72.76.233]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8AHijvb022186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 10 Sep 2006 10:44:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=Zn+gJiBUvlw77BMsgD13AhSB5p+RAYzYHTlVYAKb/i/kcwj4dW7D6lBfksHK6sPp Message-ID: <45044F0C.6020305@yahoo-inc.com> Date: Sun, 10 Sep 2006 10:44:44 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "'LTRU Working Group'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ltru] draft ID nearly ready... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I have posted my first cut at a new I-D on my website: http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-00.txt http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-00.html In this version I have incorporated all of the RFC Editor's changes to the old draft-registry. I have also inserted text for ISO 639-3, although by no mean all such text that we've discussed. I have also taken the liberty to remove some material that pertains to the transition from 3066 and to modify the text describing the update of the registry. Comments welcome, although I'll probably post this version shortly (after creating a diff, running the spellchecker, and other preparatory stuff). Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 13:52:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMTTl-0003Nj-Dp; Sun, 10 Sep 2006 13:52:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMTTk-0003Ne-5L for ltru@lists.ietf.org; Sun, 10 Sep 2006 13:52:24 -0400 Received: from mta2.iomartmail.com ([62.128.193.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMTTi-0005qK-PM for ltru@lists.ietf.org; Sun, 10 Sep 2006 13:52:24 -0400 Received: from mta2.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta2.iomartmail.com (8.12.8/8.12.8) with ESMTP id k8AHqBfx006477; Sun, 10 Sep 2006 18:52:11 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta2.iomartmail.com (8.12.8/8.12.8) with ESMTP id k8AHq4Er006268; Sun, 10 Sep 2006 18:52:10 +0100 Message-Id: <200609101752.k8AHq4Er006268@mta2.iomartmail.com> From: "Debbie Garside" To: "'Frank Ellermann'" , , "'John Cowan'" Subject: RE: [Ltru] Re: 3066ter encompassed languages Date: Sun, 10 Sep 2006 18:52:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcbU+B7Hagc/XmHWQtKidKZwK7nB4QACNNqA In-Reply-To: <45043FEE.5B3B@xyzzy.claranet.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellerman wrote: > John Cowan wrote: > > > For example, 639-1 (and a fortiori 4646) has "ar", meaning simply > > "Arabic", a term encompassing some 30 distinct languages. > Rather than > > requiring people in search of any sort of Arabic to search for 30 > > distinct tags, or requiring matchers to keep a table > mapping "ar" to > > all those tags, we instead require taggers specifying (say) > Algerian > > Arabic to use "ar-aao" instead of just "aao". That way, > searches for > > "ar" will automatically match. > > So far okay. And are we sure that this info has to be made > explicit in billions of tags instead of once in the registry ? > > In many cases the tags don't offer this redundancy. If I'm > looking for "de" nobody can (based alone on the registry) > automatically guess that I can also read "nds". This is perhaps where the hierarchical system of ISO 639-6 comes in. Being able to lookup the parent tag. As 639-6 is still in development it would be easy to incorporate ISO 639-1 codes where relevant; in the same way as ISO 639-6 is being used. Best regards Debbie _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 15:17:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMUnr-0000P8-VH; Sun, 10 Sep 2006 15:17:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMUlz-0008EN-7x for ltru@ietf.org; Sun, 10 Sep 2006 15:15:19 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMUXC-00047m-7t for ltru@ietf.org; Sun, 10 Sep 2006 15:00:05 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GMUXB-0007f5-JH; Sun, 10 Sep 2006 15:00:01 -0400 Date: Sun, 10 Sep 2006 15:00:01 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: 3066ter encompassed languages Message-ID: <20060910190001.GA23913@ccil.org> References: <004101c6d3d3$283f38f0$6401a8c0@DGBP7M81> <450294B2.5319@xyzzy.claranet.de> <20060909155329.GL22017@ccil.org> <45043FEE.5B3B@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45043FEE.5B3B@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > In many cases the tags don't offer this redundancy. If I'm > looking for "de" nobody can (based alone on the registry) > automatically guess that I can also read "nds". True. For that matter, it takes no account of the fair-to-usable mutual intelligibility between the mainland Scandinavian languages, not to mention thousands of other such situations worldwide. (English is unusually isolated in this respect, except for the related creoles.) However, the fact that you can read "nds" is a fact about you, not about everyone who can read "de". -- Even the best of friends cannot John Cowan attend each others' funeral. cowan@ccil.org --Kehlog Albran, The Profit http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 15:55:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMVP1-0001Jp-VS; Sun, 10 Sep 2006 15:55:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMVP1-0001Hx-8h for ltru@lists.ietf.org; Sun, 10 Sep 2006 15:55:39 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMVOz-0001Co-TP for ltru@lists.ietf.org; Sun, 10 Sep 2006 15:55:39 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GMVOu-00010a-T1 for ltru@lists.ietf.org; Sun, 10 Sep 2006 21:55:32 +0200 Received: from du-001-109.access.de.clara.net ([212.82.227.109]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Sep 2006 21:55:32 +0200 Received: from nobody by du-001-109.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Sep 2006 21:55:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 10 Sep 2006 21:51:40 +0200 Organization: Lines: 33 Message-ID: <45046CCC.58FF@xyzzy.claranet.de> References: <45044F0C.6020305@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-109.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [Ltru] Re: draft ID nearly ready... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > after creating a diff In USEFOR I've recently learned how to do this with any URLs in five steps. Take two URLs (1) like: ftp://ftp.rfc-editor.org/in-notes/rfc4646.txt http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-00.txt Then add http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1= before the older URL (2). Add &url2= before the 2nd URL (3), and finally add &difftype=--hwdiff at the end (4), resulting in one monstrous (here folded) URL: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1= ftp://ftp.rfc-editor.org/in-notes/rfc4646.txt&url2= http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-00.txt &difftype=--hwdiff Check that this works, and then create a tiny URL (5) for it: http://tinyurl.com/hq367 IETF tools server magic, credits to Henrik. Other types are --chbars (only the new text with a change bar in the 1st column), and --abdiff (like the default side by side diff, but arranged for narrow browser windows). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 17:02:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMWRV-0001K1-QT; Sun, 10 Sep 2006 17:02:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMWRU-0001Jv-GK for ltru@lists.ietf.org; Sun, 10 Sep 2006 17:02:16 -0400 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMWRS-0003xf-W6 for ltru@lists.ietf.org; Sun, 10 Sep 2006 17:02:16 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1148532nfc for ; Sun, 10 Sep 2006 14:02:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=XmHQbXA/7Yfc6VewbS7kdiIuAUB2sfnVR/QmbuDH2U7+YNftf4g0b+LfC0MlinK2gqfvMX2wyrR8Sy6voGICDX0g3tpCW1ftWvTgnpnvolWCFEYxFtNI905MqmwqWLQubCk3WoOLnhkN3+/zQjly9ydi8SEVoj8jwazf9xse97I= Received: by 10.49.20.5 with SMTP id x5mr7196846nfi; Sun, 10 Sep 2006 14:02:13 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Sun, 10 Sep 2006 14:02:13 -0700 (PDT) Message-ID: <30b660a20609101402v15e3c77aqd5cf2a126b57ba9b@mail.gmail.com> Date: Sun, 10 Sep 2006 15:02:13 -0600 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: draft ID nearly ready... In-Reply-To: <45046CCC.58FF@xyzzy.claranet.de> MIME-Version: 1.0 References: <45044F0C.6020305@yahoo-inc.com> <45046CCC.58FF@xyzzy.claranet.de> X-Google-Sender-Auth: a1784d1dd1487722 X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0873859185==" Errors-To: ltru-bounces@ietf.org --===============0873859185== Content-Type: multipart/alternative; boundary="----=_Part_4831_15145254.1157922133785" ------=_Part_4831_15145254.1157922133785 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I wish there were tools like that for the HTML version, since that is so vastly easier to read! Mark On 9/10/06, Frank Ellermann wrote: > > Addison Phillips wrote: > > > after creating a diff > > In USEFOR I've recently learned how to do this with any URLs > in five steps. Take two URLs (1) like: > > ftp://ftp.rfc-editor.org/in-notes/rfc4646.txt > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-00.txt > > Then add > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1= > before the older URL (2). Add > &url2= > before the 2nd URL (3), and finally add > &difftype=--hwdiff > at the end (4), resulting in one monstrous (here folded) URL: > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1= > ftp://ftp.rfc-editor.org/in-notes/rfc4646.txt&url2= > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-00.txt > &difftype=--hwdiff > > Check that this works, and then create a tiny URL (5) for it: > http://tinyurl.com/hq367 > > IETF tools server magic, credits to Henrik. Other types are > --chbars (only the new text with a change bar in the 1st > column), and --abdiff (like the default side by side diff, > but arranged for narrow browser windows). > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_4831_15145254.1157922133785 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I wish there were tools like that for the HTML version, since that is so vastly easier to read!

Mark


On 9/10/06, Frank Ellermann < nobody@xyzzy.claranet.de> wrote:
Addison Phillips wrote:

> after creating a diff

In USEFOR I've recently learned how to do this with any URLs
in five steps.  Take two URLs (1) like:

ftp://ftp.rfc-editor.org/in-notes/rfc4646.txt
http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-00.txt

Then add
http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=
before the older URL (2). Add
&url2=
before the 2nd URL (3), and finally add
&difftype=--hwdiff
at the end (4), resulting in one monstrous (here folded) URL:

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=
ftp://ftp.rfc-editor.org/in-notes/rfc4646.txt&url2=
http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-00.txt
&difftype=--hwdiff

Check that this works, and then create a tiny URL (5) for it:
http://tinyurl.com/hq367

IETF tools server magic, credits to Henrik.  Other types are
--chbars (only the new text with a change bar in the 1st
column), and --abdiff (like the default side by side diff,
but arranged for narrow browser windows).

Frank



_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

------=_Part_4831_15145254.1157922133785-- --===============0873859185== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0873859185==-- From ltru-bounces@ietf.org Sun Sep 10 17:31:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMWtT-0006YT-CC; Sun, 10 Sep 2006 17:31:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMWtS-0006YL-C3 for ltru@ietf.org; Sun, 10 Sep 2006 17:31:10 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMWtQ-0007Rp-PL for ltru@ietf.org; Sun, 10 Sep 2006 17:31:10 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1151803nfc for ; Sun, 10 Sep 2006 14:31:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=VBKKAcVual61odN3O4rvtIkLDHkTcd1NxOl7ZFaP6APCbDjVyO9Ec8PSSzYHGaj9zVm7w9sPl0r53RGpt6tLjMivp7xu1RMc1SF3CC1aMN9liAzSoERDAPmaWA3zdhC3/4LOPpiIvkdRijAOzYmaNItx4JlTn7hAaG//7MtmTmA= Received: by 10.49.94.20 with SMTP id w20mr7217466nfl; Sun, 10 Sep 2006 14:31:05 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Sun, 10 Sep 2006 14:31:05 -0700 (PDT) Message-ID: <30b660a20609101431y5188d132ha72dd758f0bec5c2@mail.gmail.com> Date: Sun, 10 Sep 2006 15:31:05 -0600 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] draft ID nearly ready... In-Reply-To: <45044F0C.6020305@yahoo-inc.com> MIME-Version: 1.0 References: <45044F0C.6020305@yahoo-inc.com> X-Google-Sender-Auth: 8a62dd569b8d041a X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2039867775==" Errors-To: ltru-bounces@ietf.org --===============2039867775== Content-Type: multipart/alternative; boundary="----=_Part_5211_25517770.1157923865501" ------=_Part_5211_25517770.1157923865501 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Nice. Some quick notes: 1. You changed "two-character" to drop the hyphen. On the purely stylistic side, I prefer "two-character codes" over "two character codes" since it reduces ambiguity, and for consistency we also get "two-character code". 2. Since we know that there will be only one extlang, do we want to change the following? >There MAY be up to three extended language subtags. The disadvantage is that some tags will be well-formed (although invalid) on past parsers but not this one. 3. I disagree with removing the check on prefixes of variant tags in *validating* parsers. (Validating parsers have access to the registry -- well-formedness doesn't and shouldn't.) o For variant and extended language subtags, if the registry contains one or more 'Prefix' fields for that subtag, check that the tag matches at least one prefix. *'Prefix' field associated with the subtag.* The tag matches if all the subtags in the 'Prefix' also appear in the tag. For example, the prefix "es-CO" matches the tag "es-Latn-CO-x-private" because both the 'es' language subtag and 'CO' region subtag appear in the tag.** => o For variant subtags, if there are any 'Prefix' fields associated with the tag, check that the tag matches at least one of the * 'Prefix' fields.* The tag matches if all the subtags in the 'Prefix' also appear in the tag. [fix example] o For extended language subtags, check that the tag matches the * 'Prefix' field associated with the subtag.* The tag matches if all the subtags in the 'Prefix' also appear in the tag. [fix example] I realize that some people (including yourself) want to disallow variants without prefixes. I don't agree with that. We had left off the ability to have registered region codes and scripts, because they could be handled via variants with no Prefix. We should not rush to eliminiate this feature without thoroughly discussing the consequences. My changes here just reconcile the issue between validation and registration. 4. Correct the addition of Prefix. 3. Values in the field 'Prefix' MAY be added to records of type 'variant' via the registration process. => 3. Values in the field 'Prefix' MUST NOT be added to records of type 'extlang' or to records of type 'variant' that do not have any 'Prefix' values. Values MAY be added to records of type 'variant' that already have a field of type 'Prefix' via the registration process. 5. Restore the change from U5.0 reference. [Unicode] Unicode Consortium, "The Unicode *Consortium. The Unicode Standard, Version 4.1.0, defined by: The Unicode* Standard, Version 5.0", Boston, *4.0 (Boston,* MA, Addison-Wesley, 2007. *2003.* ISBN 0-321- 48091-0. *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.* 6. We'll have to fix the following: At the time this document was written, there were only four such codes: 830 (Channel Islands), 831 (Guernsey), 832 (Jersey), and 833 (Isle of Man). This way, UN M.49 codes remain available as the value of last resort in cases where ISO 3166 reassigns a deprecated value in the registry. ** ------=_Part_5211_25517770.1157923865501 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Nice. Some quick notes:

1. You changed "two-character" to drop the hyphen. On the purely stylistic side, I prefer "two-character codes" over "two character codes" since it reduces ambiguity, and for consistency we also get "two-character code".

2. Since we know that there will be only one extlang, do we want to change the following?

>There MAY be up to three extended language subtags.

The disadvantage is that some tags will be well-formed (although invalid) on past parsers but not this one.

3. I disagree with removing the check on prefixes of variant tags in *validating* parsers. (Validating parsers have access to the registry -- well-formedness doesn't and shouldn't.)

   o  For 
variant and extended language subtags, if the registry
      contains one or more 'Prefix' fields for that subtag, check that the tag matches at least
      one 
prefix. 'Prefix' field associated with the subtag.  The tag matches if
      all the subtags in the 'Prefix' also appear in the tag.  For

      example, the prefix "es-CO" matches the tag "es-Latn-CO-x-private"
      because both the 'es' language subtag and 'CO' region subtag
      appear in the tag.
=>
   o  For variant subtags, if there are any 'Prefix' fields associated
      with the tag, check that the tag matches 
at least one of the
      'Prefix' fields.
  The tag matches if
      all the subtags in the 'Prefix' also appear in the tag.  [fix example]
   o  For extended language subtags, check that the tag matches the
      
'Prefix' field associated with the subtag.  The tag matches if
      all the subtags in the 'Prefix' also appear in the tag.  [fix example]
I realize that some people (including yourself) want to disallow variants without prefixes. I don't agree with that. We had left off the ability to have registered region codes and scripts, because they could be handled via variants with no Prefix. We should not rush to eliminiate this feature without thoroughly discussing the consequences. My changes here just reconcile the issue between validation and registration.

4. Correct the addition of Prefix.
   3.   Values in the field 'Prefix' MAY be added to records of type
        'variant' via the registration process.
=>
   3.   Values in the field 'Prefix' MUST NOT be added to records

        of type 'extlang' or to records of type 'variant' 
        that do not have any 'Prefix' values. Values
        MAY be added to records of type 'variant' that already
        have a field of type 'Prefix' via the registration process.



5. Restore the change from U5.0 reference.

   [Unicode]  Unicode Consortium, "The Unicode Consortium. The Unicode
              Standard, Version 4.1.0, defined by: The Unicode
 Standard,
              Version
                  5.0", Boston, 4.0 (Boston, MA, Addison-Wesley, 
2007. 2003. ISBN 0-321-
                  48091-0.
              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.

6. We'll have to fix the following:

        At the time this document was written, there were
        only four such codes: 830 (Channel Islands), 831 (Guernsey), 832

        (Jersey), and 833 (Isle of Man).  This way, UN M.49 codes remain
        available as the value of last resort in cases where ISO 3166
        reassigns a deprecated value in the registry.

------=_Part_5211_25517770.1157923865501-- --===============2039867775== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2039867775==-- From ltru-bounces@ietf.org Sun Sep 10 21:48:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMati-0002rY-Un; Sun, 10 Sep 2006 21:47:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMath-0002p8-JM for ltru@ietf.org; Sun, 10 Sep 2006 21:47:41 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMatf-000673-7R for ltru@ietf.org; Sun, 10 Sep 2006 21:47:41 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060911014734.UPQZ29000.mta13.adelphia.net@DGBP7M81> for ; Sun, 10 Sep 2006 21:47:34 -0400 Message-ID: <002901c6d544$3f4cad80$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 10 Sep 2006 18:47:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Subject: [Ltru] ISO 639-3 description changes (was: Re: 3066ter encompassed languages) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org We have been talking about the descriptions ("reference names") used in the current draft tables for ISO 639-3, and how they differ sometimes from those used in ISO 639-1 and 639-2 and thus in the Language Subtag Registry. In this post, I will classify the differences into two groups, and argue that names in the first group should be added to the Registry, while names in the second group should replace the existing descriptions. Disclaimer: I know that the currently available 639-3 tables are draft, and are subject to change, and that the JAC plans to discuss cases such as Malay and possibly assign different names before the standard is published. However, our first draft documents for LTRU 2.0 are due in 3 weeks and I feel we have to discuss this issue and develop some rules now, even if the exact languages involved may change in the future. Group A: These are cases where ISO 639-3 assigns a (usually slightly) different name from 639-2. Often it is simply an inverted form of what is already there. In only one case -- "Gaelic (Scots)" -- does the new name include a parenthetical comment, and this appears to be explanatory in nature rather than necessary to make a distinction. For these cases, I suggest *adding* the 639-3 name as an additional Description field. I don't expect any of these to be controversial. cu: Church Slavic; Old Slavonic; Church Slavonic; Old Bulgarian; Old Church Slavonic 639-3 adds: Slavic, Church frr: Northern Frisian 639-3 adds: Frisian, Northern fy: Western Frisian 639-3 adds: Frisian, Western gd: Gaelic; Scottish Gaelic 639-3 adds: Gaelic (Scots) ii: Sichuan Yi 639-3 adds: Yi, Sichuan mh: Marshallese 639-3 adds: Marshall alt: Southern Altai 639-3 adds: Altai, Southern dsb: Lower Sorbian 639-3 adds: Sorbian, Lower frs: Eastern Frisian 639-3 adds: Frisian, Eastern gsw: Swiss German; Alemanic 639-3 adds: Schwyzerdütsch (which of course would go into the Registry as "Schwyzerdütsch") hsb: Upper Sorbian 639-3 adds: Sorbian, Upper nso: Northern Sotho; Pedi; Sepedi 639-3 adds: Sotho, Northern nwc: Classical Newari; Old Newari; Classical Nepal Bhasa 639-3 adds: Newari, Classical rup: Aromanian; Arumanian; Macedo-Romanian 639-3 adds: Romanian, Macedo sam: Samaritan Aramaic 639-3 adds: Aramaic, Samaritan srn: Sranan Tongo 639-3 adds: Sranan Group B: These are cases where the ISO 639-3 name is the same as in 639-2, but with a parenthetical note added. This note is always either: (a) the word "generic", used to distinguish a macrolanguage from a specific language indicated by the word "specific", OR (b) the name of a country, used to distinguish the language from a completely different language with the same name, associated with a different country. For these cases, there will be a pair of language subtags with the same base name -- for example, "Kamba (Kenya)" and "Kamba (Brazil)". I contend that the presence of both such languages means it would be misleading and inappropriate to list simply "Kamba" as the Description for one of them, as we currently do for subtag "kam". Therefore, I believe we should *replace* the existing (ISO 639-2-based) Description with the reference name from ISO 639-3. Note that I do *not* consider this tantamount to "editorializing" or trying to "improve upon the raw data" in the sense of playing with apostrophes. I believe this is necessary to avoid confusion and mistagging. ms: Malay 639-3 changes this to: Malay (generic) sw: Swahili 639-3 changes this to: Swahili (generic) ain: Ainu 639-3 changes this to: Ainu (Japan) bas: Basa 639-3 changes this to: Basa (Cameroon) bem: Bemba 639-3 changes this to: Bemba (Zambia) chm: Mari 639-3 changes this to: Mari (Russia) doi: Dogri 639-3 changes this to: Dogri (generic) fan: Fang 639-3 changes this to: Fang (Equatorial Guinea) gba: Gbaya 639-3 changes this to: Gbaya (Central African Republic) kam: Kamba 639-3 changes this to: Kamba (Kenya) kok: Konkani 639-3 changes this to: Konkani (generic) men: Mende 639-3 changes this to: Mende (Sierra Leone) war: Waray 639-3 changes this to: Waray (Philippines) -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 • UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 22:00:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMb60-0000Zg-4L; Sun, 10 Sep 2006 22:00:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMb5y-0000ZY-JV for ltru@ietf.org; Sun, 10 Sep 2006 22:00:22 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMb5x-0008Fv-BR for ltru@ietf.org; Sun, 10 Sep 2006 22:00:22 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060911020020.BPVN10083.mta9.adelphia.net@DGBP7M81> for ; Sun, 10 Sep 2006 22:00:20 -0400 Message-ID: <003201c6d546$08241fd0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 10 Sep 2006 19:00:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Ltru] Re: 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> What if the descriptions are noticeably different between 639-2 and >> 639-3? Where do we draw the line without being arbitrary? > > The line is "whatever 639-2 says" for a tag derived from 639-2. I claim it is more complicated than that, when 639-2 has coded a "language" called Malay that 639-3 actually treats as several languages, one of which is called Malay and the others of which are called something different. >> Which is better for avoiding confusion with "Waray (Australia)"? > > 639-3 . Propose a rule how to smuggle Waray (Philippines) into the > 639-2 entry. "Comment" is my first idea. Or "let's see how they sort > it out" - Peter said that will be done in time. I don't like using comments for information that is crucial to choosing the right subtag. Suppose you're looking for the Ainu language spoken in China, which is related to Uyghur and has many more speakers than the Japanese language of the same name which exists in 639-2. Should you have to look in the comments to find which Ainu is which? >> I'm in favor of adding the parenthesized country names introduced in >> 639-3, when they serve to distinguish two languages with otherwise >> identical names. > > If it has an obvious pattern we can create a rule for it. See my previous post. When 639-3 changes a 639-2 name by adding a country name or the word "generic", replace the old Description with the new one. Otherwise, add the new Description to the existing ones. That's a rule based on an obvious pattern. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 • UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 22:17:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMbMz-0008CG-IF; Sun, 10 Sep 2006 22:17:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMbMy-0008C6-H3 for ltru@ietf.org; Sun, 10 Sep 2006 22:17:56 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMbMx-0002GD-9n for ltru@ietf.org; Sun, 10 Sep 2006 22:17:56 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060911021754.MSLK23453.mta11.adelphia.net@DGBP7M81> for ; Sun, 10 Sep 2006 22:17:54 -0400 Message-ID: <003a01c6d548$7c4cb000$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 10 Sep 2006 19:17:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ltru] Deprecated (was: Re: 3066ter encompassed languages) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > I would not object to a new "discouraged" status intermediate between > deprecated and encouraged. "Deprecated" in RFC 4646 is already a rather gentle form of discouragement. It doesn't seem quite as much of an offense in RFC 4646 to create a deprecated tag like "iw" as it is in Unicode to use a character like U+0340. Note that Unicode did create a de-facto "strongly discouraged" status for the Plane 14 tag characters, slightly below full Deprecated status (which is also defined using the words "strongly discouraged"). -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 • UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 22:59:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMc0p-0000UY-Av; Sun, 10 Sep 2006 22:59:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMc0m-0000Ot-Ew for ltru@ietf.org; Sun, 10 Sep 2006 22:59:04 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMc0k-0008ML-6j for ltru@ietf.org; Sun, 10 Sep 2006 22:59:04 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060911025857.SJNE27224.mta10.adelphia.net@DGBP7M81> for ; Sun, 10 Sep 2006 22:58:57 -0400 Message-ID: <05a101c6d54e$3844dbc0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 10 Sep 2006 19:58:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ltru] Re: Fw: RFC 4645 on Initial Language Subtag Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > Based on how the last round went, I think the WG's decision to use an > internet draft was correct. > > I think the WG's decision to publish to send that material through the > RFC publication process was also good, inasmuch as it did elicit > useful comments, and gave us the requisite paper trail to deal with > real or imagined procedural problems. Fair enough, then. But I don't want to hear any complaints from others that an 800-plus-page I-D is too long or unwieldy, or that writing one is an exercise in egotism or self-aggrandizement (I don't remember who said that last time). > I think the final decision to elide the interesting parts was perhaps > unfortunate, but also understandable, given the onslaught the IETF has > been suffering. Actually I thought that had been the plan for many months. We knew the real Registry would see many updates and didn't want people to use the initial-registry snapshot as a substitute. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 • UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 23:20:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMcL7-0000yi-Cz; Sun, 10 Sep 2006 23:20:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMcL6-0000yd-Uj for ltru@ietf.org; Sun, 10 Sep 2006 23:20:04 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMcL5-0003K8-Ku for ltru@ietf.org; Sun, 10 Sep 2006 23:20:04 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060911032001.YPPE29000.mta13.adelphia.net@DGBP7M81>; Sun, 10 Sep 2006 23:20:01 -0400 Message-ID: <05a901c6d551$295fa880$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 10 Sep 2006 20:19:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Eric Muller Subject: [Ltru] Re: Up-to-date copies of the LSR X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Randy Presuhn scripsit: > >>> Having an up-to-date copy of the Registry is something that should >>> be encouraged. >> >> As a technical contributor, I believe this would be a grave mistake, >> unless we *severely* qualify what is meant by "user." I believe that >> vast majority of users have no need whatsoever for language tag >> validators. Normal users should never even see language tags, much >> less be creating them. Language tags used in protocol should be put >> there by software as a result of other user choices. I think the >> only folks who should be using tag validators are the developers of >> applications which generate language tags. These are hardly typical >> "users". Put it this way: The reason the Registry gets updated is to make tagging options available that were previously unavailable -- for example, "zza" or "GG". It follows that those options are not available except in conjunction a with sufficiently recent version of the Registry. > I don't think it's so simple. I've been talking with Eric Muller of > udhrinunicode.org [note: URL corrected here], who's developing Unicode > plain-text versions of the Universal Declaration of Human Rights in a > large variety of languages. Currently he uses Ethnologue tags, and > he's asked me whether a RFC4646bis prototype evaluator is available so > he can look into converting to that standard when it becomes > available. (Doug?) Yes? Oh. Well, my tag generator and validator, called LTag (which should be announced shortly), works equally well with the existing 4646 Registry and with a 4646bis-aware prototype Registry that includes extlangs. Obviously it would be ill-advised to release that prototype -- in the DLL form that LTag uses, or any other form -- until we've at least had a first draft of 4645bis. Watch the space. > I think Doug means not that people should be encouraged to pull the > LSR dynamically, but rather that programs that encapsulate the state > of the LSR (like his Windows version) should be made widely available > and updated fairly regularly, monthly or every two months or whatever. That's what I meant to say, yes. It's certainly not the case that everyone who generates or receives language tags needs to be assured of having the latest Registry every time. It's only important when trying to generate or interpret a tag that is not valid in one's own (possibly outdated) version. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 • UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 23:24:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMcPm-0003BV-3W; Sun, 10 Sep 2006 23:24:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMcPl-0003BQ-7K for ltru@ietf.org; Sun, 10 Sep 2006 23:24:53 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMcPj-0004Ai-Vn for ltru@ietf.org; Sun, 10 Sep 2006 23:24:53 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060911032451.TJEM27224.mta10.adelphia.net@DGBP7M81> for ; Sun, 10 Sep 2006 23:24:51 -0400 Message-ID: <05ad01c6d551$d683ffc0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 10 Sep 2006 20:24:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ltru] Re: 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> For example, 639-1 (and a fortiori 4646) has "ar", meaning simply >> "Arabic", a term encompassing some 30 distinct languages. Rather >> than requiring people in search of any sort of Arabic to search for >> 30 distinct tags, or requiring matchers to keep a table mapping "ar" >> to all those tags, we instead require taggers specifying (say) >> Algerian Arabic to use "ar-aao" instead of just "aao". That way, >> searches for "ar" will automatically match. > > So far okay. And are we sure that this info has to be made explicit > in billions of tags instead of once in the registry ? Only in those tags where "Algerian Saharan Spoken Arabic" needs to be explicitly noted, where just plain "Arabic" would be insufficient. Probably not that many billions. > Last chance to pull a "Suppress-Macrolanguage" SHOULD in 4646bis (as > in SHOULD aao, or SHOULD NOT ar-aao). Yeah. That would be a *great* can of worms for us to open. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 • UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 23:27:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMcSW-0003ex-SB; Sun, 10 Sep 2006 23:27:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMcSV-0003ej-9x for ltru@ietf.org; Sun, 10 Sep 2006 23:27:43 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMcSU-0004qB-3c for ltru@ietf.org; Sun, 10 Sep 2006 23:27:43 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GMcST-0001Uu-Q5; Sun, 10 Sep 2006 23:27:41 -0400 Date: Sun, 10 Sep 2006 23:27:41 -0400 To: Doug Ewell Subject: Re: [Ltru] ISO 639-3 description changes (was: Re: 3066ter encompassed languages) Message-ID: <20060911032741.GE23913@ccil.org> References: <002901c6d544$3f4cad80$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002901c6d544$3f4cad80$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > In this post, I will classify the differences into two groups, and argue > that names in the first group should be added to the Registry, while > names in the second group should replace the existing descriptions. Now that I've seen the data, I agree entirely with Doug's proposals. Additional name, add it. Disambiguation, use it instead. Anything else will just induce confusion. -- While staying with the Asonu, I met a man from John Cowan the Candensian plane, which is very much like cowan@ccil.org ours, only more of it consists of Toronto. http://:www.ccil.org/~cowan --Ursula K. Le Guin, Changing Planes _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 23:30:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMcVB-0005lt-PS; Sun, 10 Sep 2006 23:30:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMcVA-0005ii-78 for ltru@ietf.org; Sun, 10 Sep 2006 23:30:28 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMcV8-0005UC-Tk for ltru@ietf.org; Sun, 10 Sep 2006 23:30:28 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060911033022.ZCOE29000.mta13.adelphia.net@DGBP7M81> for ; Sun, 10 Sep 2006 23:30:22 -0400 Message-ID: <05b101c6d552$9bb45880$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 10 Sep 2006 20:30:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ltru] Re: 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> That's a problem for the ietf-languages@iana.org list. > > The "description" shouldn't be their territory, it should be fixed in > the sources. For 4646bis I'd like a statement that we expect all > primary and extlang tags to use a unique namespace (apparent "dupes" > limited to grandfathered tags). We intentionally made it possible, in Section 3.4, to change the description "Upper Volta" to "Burkina Faso" to match changes in usage. Probably that one would be implemented by adding the new name and keeping the old, though. > But we cannot guarantee that there's only one non-deprecated subtag > for a given (primary or extlang) description. With an example if it > exists, maybe "Malay". That's why I recommend using the 639-3 names "Malay (generic)" and "Malay (specific)" and getting rid of just plain "Malay". -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 • UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 10 23:55:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMctF-0000mJ-7l; Sun, 10 Sep 2006 23:55:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMctD-0000mD-BM for ltru@ietf.org; Sun, 10 Sep 2006 23:55:19 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMctB-0001iB-SP for ltru@ietf.org; Sun, 10 Sep 2006 23:55:19 -0400 Received: from [10.72.76.233] (snvvpn2-10-72-76-c233.corp.yahoo.com [10.72.76.233]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8B3tB2D042496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Sep 2006 20:55:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=0WyH9DrCOA1wRjJAIl2Kb8Ug68nkMvW3XSi2FsO0hkjj94jc34MNkKO3PFMVbUF4 Message-ID: <4504DE1F.9090707@yahoo-inc.com> Date: Sun, 10 Sep 2006 20:55:11 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] draft ID nearly ready... References: <45044F0C.6020305@yahoo-inc.com> <30b660a20609101431y5188d132ha72dd758f0bec5c2@mail.gmail.com> In-Reply-To: <30b660a20609101431y5188d132ha72dd758f0bec5c2@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Some comments follow. > > 1. You changed "two-character" to drop the hyphen. On the purely stylistic > side, I prefer "two-character codes" over "two character codes" since it > reduces ambiguity, and for consistency we also get "two-character code". Where? I thought I was pretty consistent in *including* the hyphens in the new draft. > > 2. Since we know that there will be only one extlang, do we want to change > the following? > >> There MAY be up to three extended language subtags. I don't know that we know that yet. So I didn't change it. I'm also reluctant to remove it, even if, in practice, only one extlang can occur. We might include text to reserve additional extlangs for future standardization instead. > > 3. I disagree with removing the check on prefixes of variant tags in > *validating* parsers. (Validating parsers have access to the registry -- > well-formedness doesn't and shouldn't.) Your proposed changes prevent informative registration of prefixes for a variant. A lot of people +1'ed removing the check because it supports our (meaning "Mark and Addison's") original idea that this was informative information. With my proposal, "tlh-western" (let's pretend you registered it for a second) is as valid as "hy-western", but "hy-western" actually has a registered meaning. "tlh-western" is junk... but so are "tld-CO", "tlh-Latg", and "tlh-Latn-AQ". Each of those is perfectly "valid", if entirely stupid. I think that removing the prefix check from variant requirements allows for both generic variants and the development of additional prefixes over time with the least disruption to end users. It is entirely in keeping with the IETF's koan "be strict in what you emit and promiscuous in what you accept". Since "validation" is usually on the accept side........ > > I realize that some people (including yourself) want to disallow variants > without prefixes. That would be a mis-reading of my intent. I believe what I did was suggest that we not register a subtag without a prefix at present while considering problems with validation, etc. I actually do support (in general) the idea of generic variants, provided we have a decent understanding of them. > I don't agree with that. We had left off the ability to > have registered region codes and scripts, because they could be handled via > variants with no Prefix. We should not rush to eliminiate this feature > without thoroughly discussing the consequences. My changes here just > reconcile the issue between validation and registration. +1, only see below. > > 4. Correct the addition of Prefix. > > 3. Values in the field 'Prefix' MAY be added to records of type > 'variant' via the registration process. > => > 3. Values in the field 'Prefix' MUST NOT be added to records > of type 'extlang' or to records of type 'variant' > that do not have any 'Prefix' values. Values > MAY be added to records of type 'variant' that already > have a field of type 'Prefix' via the registration process. I'm not sure that the text about extlangs is necessary per-se. I think it is probably a true requirement, but it may be covered by other stability requirements. (I'd support including it for precision, though). I don't agree with it about variants. By eliminating validation of the prefix, we achieve the same effect, while allowing for registration of useful informative information (that is, here is a subtag that means "western dialect"; with 'hy' it means a particular Armenian dialect--it is probably a mistake to use it with a prefix that is unregistered). Or, to put it another way, I think we're in violent agreement, but I like my solution (making all variants somewhat generic, but ill-considered with other than a registered prefix) better than yours (there is a sharp distinction between generic and non-generic variants) :-). > > > 5. Restore the change from U5.0 reference. > > [Unicode] Unicode Consortium, "The Unicode *Consortium. The Unicode > Standard, Version 4.1.0, defined by: The Unicode* Standard, > Version > 5.0", Boston, *4.0 (Boston,* MA, Addison-Wesley, > 2007. *2003.* ISBN 0-321- > 48091-0. > *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.* Argh. I missed that change. > > 6. We'll have to fix the following: > > At the time this document was written, there were > only four such codes: 830 (Channel Islands), 831 (Guernsey), 832 > (Jersey), and 833 (Isle of Man). This way, UN M.49 codes remain > available as the value of last resort in cases where ISO 3166 > reassigns a deprecated value in the registry. > Good catch. -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 00:02:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMd0O-0003aO-Dy; Mon, 11 Sep 2006 00:02:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMd0N-0003Xl-0X for ltru@lists.ietf.org; Mon, 11 Sep 2006 00:02:43 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMd0L-0003OE-JJ for ltru@lists.ietf.org; Mon, 11 Sep 2006 00:02:42 -0400 Received: from [10.72.76.233] (snvvpn2-10-72-76-c233.corp.yahoo.com [10.72.76.233]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8B42VaG042766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Sep 2006 21:02:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=wBDLhrTvwnOYZEnoVC/QpNrWTFWk9DXSCjDQj9LPCuWt785d9STyahDSsEPVSMhB Message-ID: <4504DFD7.6050207@yahoo-inc.com> Date: Sun, 10 Sep 2006 21:02:31 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: draft ID nearly ready... References: <45044F0C.6020305@yahoo-inc.com> <45046CCC.58FF@xyzzy.claranet.de> In-Reply-To: <45046CCC.58FF@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org (laughing) Yeah, I know. Where do you think my TinyURLs have been coming from? It even has the benefit of dynamically updating when I upload a corrected copy. On the other hand, I like to read the diff before I announce it. Sometimes I find more problems when I do that :-) Addison Frank Ellermann wrote: > Addison Phillips wrote: > >> after creating a diff > > In USEFOR I've recently learned how to do this with any URLs > in five steps. Take two URLs (1) like: > > ftp://ftp.rfc-editor.org/in-notes/rfc4646.txt > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-00.txt > > Then add > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1= > before the older URL (2). Add > &url2= > before the 2nd URL (3), and finally add > &difftype=--hwdiff > at the end (4), resulting in one monstrous (here folded) URL: > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1= > ftp://ftp.rfc-editor.org/in-notes/rfc4646.txt&url2= > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-00.txt > &difftype=--hwdiff > > Check that this works, and then create a tiny URL (5) for it: > http://tinyurl.com/hq367 > > IETF tools server magic, credits to Henrik. Other types are > --chbars (only the new text with a change bar in the 1st > column), and --abdiff (like the default side by side diff, > but arranged for narrow browser windows). > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 00:15:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMdCk-0000yv-5A; Mon, 11 Sep 2006 00:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMdCi-0000yk-NO for ltru@ietf.org; Mon, 11 Sep 2006 00:15:28 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMdCh-0005sR-Gp for ltru@ietf.org; Mon, 11 Sep 2006 00:15:28 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GMdCh-0004FK-6q; Mon, 11 Sep 2006 00:15:27 -0400 Date: Mon, 11 Sep 2006 00:15:27 -0400 To: Addison Phillips Subject: Re: [Ltru] draft ID nearly ready... Message-ID: <20060911041527.GF23913@ccil.org> References: <45044F0C.6020305@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45044F0C.6020305@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Comments welcome, although I'll probably post this version shortly > (after creating a diff, running the spellchecker, and other preparatory > stuff). Multiple extlang tags should be allowed in 4646bis, with recursive interpretation. The use case is this: if it turns out that ar-aao (Algerian Arabic) is really two different languages, say Northern Algerian Arabic and Southern Algerian Arabic, then 639-3 will assign two new language tags, say xxx and yyy. For backward compatibility and ease of matching, then, we register these as extlang subtags with a Prefix of ar-aao. The result is the tags ar-aao-xxx and ar-aao-yyy. Naturally we hope this won't happen, but we can't rule it out either. (What happens after two more splits? We lose.) -- John Cowan cowan@ccil.org http://ccil.org/~cowan If he has seen farther than others, it is because he is standing on a stack of dwarves. --Mike Champion, describing Tim Berners-Lee (adapted) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 00:21:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMdI4-0003Ot-Pg; Mon, 11 Sep 2006 00:21:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMdI3-0003Ok-Sv for ltru@ietf.org; Mon, 11 Sep 2006 00:20:59 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMdI2-0007TT-LR for ltru@ietf.org; Mon, 11 Sep 2006 00:20:59 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060911042055.HMCJ10083.mta9.adelphia.net@DGBP7M81> for ; Mon, 11 Sep 2006 00:20:55 -0400 Message-ID: <05c401c6d559$abcafb50$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] draft ID nearly ready... Date: Sun, 10 Sep 2006 21:20:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Disclaimer: I haven't read Addison's new draft yet. Mark Davis wrote: > 2. Since we know that there will be only one extlang, do we want to > change the following? > >>There MAY be up to three extended language subtags. > > The disadvantage is that some tags will be well-formed (although > invalid) on past parsers but not this one. -1. Extlangs are provided only by the Registry anyway, so I see no need for this breaking change. > 6. We'll have to fix the following: > > At the time this document was written, there were only four > such codes: 830 (Channel Islands), 831 (Guernsey), 832 > (Jersey), and 833 (Isle of Man). This way, UN M.49 codes > remain available as the value of last resort in cases where ISO > 3166 reassigns a deprecated value in the registry. IMHO, examples like this don't belong in 4646bis at all, only in 4645bis. Serbia and Montenegro (two separate countries now) may provide us with a new use case. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 01:11:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMe4z-0008LZ-TH; Mon, 11 Sep 2006 01:11:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMe4y-0008LU-2V for ltru@ietf.org; Mon, 11 Sep 2006 01:11:32 -0400 Received: from mta6.adelphia.net ([68.168.78.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMe4v-0007Xv-Mp for ltru@ietf.org; Mon, 11 Sep 2006 01:11:32 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060911050955.WOS28624.mta11.adelphia.net@DGBP7M81> for ; Mon, 11 Sep 2006 01:09:55 -0400 Message-ID: <05d001c6d560$8409f6a0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 10 Sep 2006 22:09:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Ltru] Comments that refer to "ISO codes" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org For certain grandfathered tags that have been deprecated in favor of ISO 639-based tags, we attached a Comments field that indicates the ISO-based nature of the Preferred-Value. (Seems repetitive to me, but that's another story.) Here's an example: > Type: grandfathered > Tag: art-lojban > Description: Lojban > Added: 2001-11-11 > Preferred-Value: jbo > Deprecated: 2003-09-02 > Comments: replaced by ISO code jbo I propose modifying these comments slightly to indicate *which* ISO standard begat the replacement tag, like this: > Comments: replaced by ISO 639-2 code jbo For consistency, we would then also add this sort of comment to existing grandfathered tags that become deprecated by one of the new 639-3-based subtags: > Type: grandfathered > Tag: zh-xiang > Description: Xiang or Hunanese > Added: 1999-12-18 > Preferred-Value: zh-hsn > Deprecated: xxxx-xx-xx > Comments: replaced by ISO 639-3 code hsn Any comments? So to speak? -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 07:34:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMk3W-0007Fw-Ij; Mon, 11 Sep 2006 07:34:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMk3V-0007Fr-Ds for ltru@ietf.org; Mon, 11 Sep 2006 07:34:25 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMk3T-0003Sx-7Y for ltru@ietf.org; Mon, 11 Sep 2006 07:34:25 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GMk3S-0006qZ-PR; Mon, 11 Sep 2006 07:34:22 -0400 Date: Mon, 11 Sep 2006 07:34:22 -0400 To: Doug Ewell Subject: Re: [Ltru] Comments that refer to "ISO codes" Message-ID: <20060911113422.GA6022@ccil.org> References: <05d001c6d560$8409f6a0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <05d001c6d560$8409f6a0$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > I propose modifying these comments slightly to indicate *which* ISO > standard begat the replacement tag, like this: I don't understand why you think this matters; can you explain? If we deprecate something in favor of an individual-language or macrolanguage code element, it'll be in -3, whether or not it's in -2. I can't imagine deprecating something in favor of a language-collection code element. -- Even the best of friends cannot John Cowan attend each others' funeral. cowan@ccil.org --Kehlog Albran, The Profit http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 08:09:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMkbJ-0004NS-Op; Mon, 11 Sep 2006 08:09:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMkbJ-0004NN-0I for ltru@lists.ietf.org; Mon, 11 Sep 2006 08:09:21 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMkbF-0008T5-K0 for ltru@lists.ietf.org; Mon, 11 Sep 2006 08:09:20 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GMkb4-0003Pd-Ts for ltru@lists.ietf.org; Mon, 11 Sep 2006 14:09:06 +0200 Received: from pd9fbad3c.dip0.t-ipconnect.de ([217.251.173.60]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Sep 2006 14:09:06 +0200 Received: from nobody by pd9fbad3c.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Sep 2006 14:09:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 11 Sep 2006 14:07:36 +0200 Organization: Lines: 13 Message-ID: <45055188.1BA1@xyzzy.claranet.de> References: <45044F0C.6020305@yahoo-inc.com> <45046CCC.58FF@xyzzy.claranet.de> <4504DFD7.6050207@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad3c.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] Re: draft ID nearly ready... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > (laughing) Yeah, I know. Where do you think my TinyURLs have > been coming from? The part with "add &difftype=--hwdiff" was new for me - with my browser the side-by-side default is precisely the only unusable format. That's why I tried to create plain text diffs based on the unpaginated output for some 4646-drafts. Complete waste of time, the &difftype=--hwdiff is fine. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 09:02:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMlQM-0001Ul-32; Mon, 11 Sep 2006 09:02:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMlQL-0001Ub-2P for ltru@lists.ietf.org; Mon, 11 Sep 2006 09:02:05 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMlQJ-0005v2-Kv for ltru@lists.ietf.org; Mon, 11 Sep 2006 09:02:05 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GMlQB-0005oj-1W for ltru@lists.ietf.org; Mon, 11 Sep 2006 15:01:55 +0200 Received: from pd9fbad3c.dip0.t-ipconnect.de ([217.251.173.60]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Sep 2006 15:01:55 +0200 Received: from nobody by pd9fbad3c.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Sep 2006 15:01:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 11 Sep 2006 14:57:16 +0200 Organization: Lines: 46 Message-ID: <45055D2C.33D8@xyzzy.claranet.de> References: <45044F0C.6020305@yahoo-inc.com> <30b660a20609101431y5188d132ha72dd758f0bec5c2@mail.gmail.com> <4504DE1F.9090707@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad3c.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [Ltru] Re: draft ID nearly ready... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I think that removing the prefix check from variant > requirements allows for both generic variants and the > development of additional prefixes over time with the > least disruption to end users. It is entirely in keeping > with the IETF's koan "be strict in what you emit and > promiscuous in what you accept". Since "validation" is > usually on the accept side........ I thought it's for (among others) online validators like Unicorn. If I'd install a validator locally I wouldn't update the registry daily, because I don't need the most recent tags worldwide. If you install it locally you'd probably try to get the most recent registry. And you'd be interested to get warnings for junk like tlh-1996 etc. > I actually do support (in general) the idea of generic > variants, provided we have a decent understanding of them. Extension registry "g". Mark's example "generic regions" below the 3166-1 level deserves its own extension registry. For a pseudo-generic "europeun" listing the prefixes of all EU languages would be a PITA, but not imposssible. And IMO still better than a true generic "europeun". [Mark about generic variants] >> We should not rush to eliminiate this feature without >> thoroughly discussing the consequences. Sure, and under RFC 4646 rules the review list is free to ignore the SHOULD. As soon as they've done this we can't twist it into a MUST anymore. But if they don't use this loophole we can block it in 4646bis. > there is a sharp distinction between generic and > non-generic variants Yes, and generic can be replaced by extension registries. Generic region variants would be a can of worms. I'm free to send "unsubscribe" to the review list if it hits the fan, others (probably including you) are not, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 09:25:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMlmh-00037o-0K; Mon, 11 Sep 2006 09:25:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMlmf-00037a-Hz for ltru@lists.ietf.org; Mon, 11 Sep 2006 09:25:09 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMlmd-0000Ts-7R for ltru@lists.ietf.org; Mon, 11 Sep 2006 09:25:09 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GMlmP-0002t4-NP for ltru@lists.ietf.org; Mon, 11 Sep 2006 15:24:54 +0200 Received: from pd9fbad3c.dip0.t-ipconnect.de ([217.251.173.60]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Sep 2006 15:24:53 +0200 Received: from nobody by pd9fbad3c.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Sep 2006 15:24:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 11 Sep 2006 15:23:17 +0200 Organization: Lines: 26 Message-ID: <45056345.129F@xyzzy.claranet.de> References: <45044F0C.6020305@yahoo-inc.com> <45046CCC.58FF@xyzzy.claranet.de> <30b660a20609101402v15e3c77aqd5cf2a126b57ba9b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad3c.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Ltru] Re: draft ID nearly ready... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > I wish there were tools like that for the HTML version, > since that is so vastly easier to read! Probably the W3C has such tools, they can generate "diffs" based on and . Pointless from my POV with an old browser not supporting these tags, but it should be what you want. The two input URLs are the HTML output of xml2rfc: http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-00.html http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html The -14 isn't exactly 4646, but you know all minor AUTH48 changes. The missing step from last draft to final RFC is a known issue, I hope they'll fix it soon (before 2008). Maybe Addison has an unofficial post-AUTH48 XML somewhere. IIRC the SPF folks tried this for 4408 (= retrofitting the Rfc-editor modifications into the XML source). Otherwise you'd need tools to create HTML from nroff, and then the diff-marked HTML based on these nroff-to-HTML versions. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 10:08:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMmSG-0006Dw-Ib; Mon, 11 Sep 2006 10:08:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMmSG-0006Dr-2N for ltru@lists.ietf.org; Mon, 11 Sep 2006 10:08:08 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMmSE-0008WO-Or for ltru@lists.ietf.org; Mon, 11 Sep 2006 10:08:08 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GMmRx-0004id-7d for ltru@lists.ietf.org; Mon, 11 Sep 2006 16:07:49 +0200 Received: from pd9fbad3c.dip0.t-ipconnect.de ([217.251.173.60]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Sep 2006 16:07:49 +0200 Received: from nobody by pd9fbad3c.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Sep 2006 16:07:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 11 Sep 2006 16:04:50 +0200 Organization: Lines: 39 Message-ID: <45056D02.7CD3@xyzzy.claranet.de> References: <002901c6d544$3f4cad80$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad3c.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [Ltru] Re: ISO 639-3 description changes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > names in the first group should be added to the Registry Okay, my KISS attack "ignore 639-3 if a tag from another source is already there" turned out to be a bad idea. > Disclaimer [x] read > I contend that the presence of both such languages means it > would be misleading and inappropriate to list simply "Kamba" > as the Description for one of them, as we currently do for > subtag "kam". Therefore, I believe we should *replace* the > existing (ISO 639-2-based) Description with the reference > name from ISO 639-3. Here I disagree, let 639-2 replace it if necessary. If you insist on it we can add a rule in 4646bis allowing the review list to remove mainly redundant and potentially misleading descriptions based on 639-2 individually at any time (in the 4645bis "date C" registry or at registration time). > I do *not* consider this tantamount to "editorializing" or > trying to "improve upon the raw data" It's very near to cherry picking, and users looking for the precise description as published in 639-2 might be confused. Debbie mentioned use cases where what you propose could remove identifiers (URNs or similar) somewhere. Weak analogoy: I could propose to replace by NAK in column 2 of u+0015. Highly desirable from my POV, but the Unicode folks would eat me alive, it breaks applications expecting in column 2. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 10:38:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMmvJ-0002Ky-4u; Mon, 11 Sep 2006 10:38:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMmvH-0002Jd-3u for ltru@ietf.org; Mon, 11 Sep 2006 10:38:07 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMmvD-0005ph-9x for ltru@ietf.org; Mon, 11 Sep 2006 10:38:07 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060911143802.YPDL10083.mta9.adelphia.net@DGBP7M81>; Mon, 11 Sep 2006 10:38:02 -0400 Message-ID: <061001c6d5af$e1ade1a0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <05d001c6d560$8409f6a0$6401a8c0@DGBP7M81> <20060911113422.GA6022@ccil.org> Subject: Re: [Ltru] Comments that refer to "ISO codes" Date: Mon, 11 Sep 2006 07:38:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >> I propose modifying these comments slightly to indicate *which* ISO >> standard begat the replacement tag, like this: > > I don't understand why you think this matters; can you explain? If we > deprecate something in favor of an individual-language or > macrolanguage code element, it'll be in -3, whether or not it's in -2. > I can't imagine deprecating something in favor of a > language-collection code element. "ISO code xx" just seems hopelessly vague to me. I'm perfectly willing to back down on this. I'd really rather do away with the self-evident comments anyway, but I understand other list member like to err on the side of more comments rather than fewer, and in any case this is much less repetitive and awful than the "hy-western" comments we considered earlier. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 10:39:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMmw9-0002nM-NB; Mon, 11 Sep 2006 10:39:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMmw7-0002hT-RV for ltru@lists.ietf.org; Mon, 11 Sep 2006 10:38:59 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMmw6-0005xs-HA for ltru@lists.ietf.org; Mon, 11 Sep 2006 10:38:59 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GMmvp-0003Ui-Mn for ltru@lists.ietf.org; Mon, 11 Sep 2006 16:38:41 +0200 Received: from pd9fbad3c.dip0.t-ipconnect.de ([217.251.173.60]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Sep 2006 16:38:41 +0200 Received: from nobody by pd9fbad3c.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Sep 2006 16:38:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 11 Sep 2006 16:35:43 +0200 Organization: Lines: 43 Message-ID: <4505743F.3AC2@xyzzy.claranet.de> References: <003201c6d546$08241fd0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad3c.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Ltru] Re: 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > I don't like using comments for information that is crucial > to choosing the right subtag. They're as good or bad as the "description" for this purpose. The source is different, "comment" is added by the review list, no "comment" if the ISO "description" is good enough. > Should you have to look in the comments to find which Ainu > is which? As soon as I find out that there are more Ainu than the one I've heard of before (which happens to be the JP Ainu) I better check what's going on. We've to add instructions for human readers trying to figure out a subtag for a given type and description anyway - they better use a list sorted by type and description (or only description). A paragraph with one simple example, nothing extraordinary. [proposed rule] > When 639-3 changes a 639-2 name by adding a country name or > the word "generic", replace the old Description with the > new one. Slightly messy, because the registered 639-2 tag apparently isn't what 639-3 considers as "generic". As a tag it has the semantics of their "specific" code. Which isn't the registered tag. Now that's confusing as soon as you try to talk about it. While "Malay is Malay (unless you want Ambonese etc.)" should be clear for readers not interested in these subtleties. > Otherwise, add the new Description to the existing ones. > That's a rule based on an obvious pattern. Yes, but I don't like its outcome. Can we do this without the "otherwise" qualifier, simply add it always as is ? For the few cases you found we don't need optimizations and convoluted special rules. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 11:25:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMnfU-0007VD-SA; Mon, 11 Sep 2006 11:25:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMnfU-0007V8-9V for ltru@lists.ietf.org; Mon, 11 Sep 2006 11:25:52 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMnfS-0006jg-Td for ltru@lists.ietf.org; Mon, 11 Sep 2006 11:25:52 -0400 Received: from [10.72.76.233] (snvvpn2-10-72-76-c233.corp.yahoo.com [10.72.76.233]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8BFPkDP069056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Sep 2006 08:25:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=bDuTuRJuO8f4blaZYJd/buLC5loqFEQ87JBnxaIUMMGSEwk4jLqFe9tZeadtsu1/ Message-ID: <45057FF8.6000602@yahoo-inc.com> Date: Mon, 11 Sep 2006 08:25:44 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: draft ID nearly ready... References: <45044F0C.6020305@yahoo-inc.com> <45046CCC.58FF@xyzzy.claranet.de> <4504DFD7.6050207@yahoo-inc.com> <45055188.1BA1@xyzzy.claranet.de> In-Reply-To: <45055188.1BA1@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I believe the wdiff feature is new: I learned about it during AUTH48 of 4646. If it isn't new, it wasn't formerly documented on the rfcdiff home page. Addison Frank Ellermann wrote: > Addison Phillips wrote: > >> (laughing) Yeah, I know. Where do you think my TinyURLs have >> been coming from? > > The part with "add &difftype=--hwdiff" was new for me - with my > browser the side-by-side default is precisely the only unusable > format. That's why I tried to create plain text diffs based on > the unpaginated output for some 4646-drafts. Complete waste of > time, the &difftype=--hwdiff is fine. > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 12:11:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMoNw-00025q-R3; Mon, 11 Sep 2006 12:11:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMoNu-00025I-Sj for ltru@ietf.org; Mon, 11 Sep 2006 12:11:46 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMoNr-0002d5-2m for ltru@ietf.org; Mon, 11 Sep 2006 12:11:46 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8BGBdD3004963 for ; Tue, 12 Sep 2006 01:11:39 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 7248_34f08144_41b0_11db_967d_0014221f2a2d; Tue, 12 Sep 2006 01:11:39 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:59222) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 12 Sep 2006 01:11:42 +0900 Message-Id: <6.0.0.20.2.20060911185050.04b403e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 11 Sep 2006 18:52:11 +0900 To: Stephane Bortzmeyer , John Cowan From: Martin Duerst Subject: Re: [Ltru] Do we need validating parsers for input? (Was: prefixes fordate variants In-Reply-To: <20060907161814.GA24475@nic.fr> References: <013c01c6d246$f8763d40$6401a8c0@DGBP7M81> <001501c6d297$cdf7c6a0$6501a8c0@oemcomputer> <20060907161134.GM14450@ccil.org> <20060907161814.GA24475@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 01:18 06/09/08, Stephane Bortzmeyer wrote: >Imagine that a process receives uk-Latb-UA. It is well-formed but not >valid (typo in the script). I presumed that the sender of this tag >would prefer to receive a message "Invalid language tag (subtag Latb >is not registered)" rather than "No document found". Don't you agree? Yes, but this looks like purely a quality of service issue. It would be a bad idea to require a protocol to do this. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 12:11:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMoNy-00027n-Uq; Mon, 11 Sep 2006 12:11:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMoNw-00025l-L2 for ltru@ietf.org; Mon, 11 Sep 2006 12:11:48 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMoNv-0002dI-2G for ltru@ietf.org; Mon, 11 Sep 2006 12:11:48 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8BGBjIi008189 for ; Tue, 12 Sep 2006 01:11:45 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 72ef_38962358_41b0_11db_938a_0014221f2a2d; Tue, 12 Sep 2006 01:11:45 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:59222) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 12 Sep 2006 01:11:51 +0900 Message-Id: <6.0.0.20.2.20060911185418.0bd61ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 11 Sep 2006 18:54:48 +0900 To: Peter Constable , From: Martin Duerst Subject: RE: [Ltru] 3066ter encompassed languages In-Reply-To: References: <20060908063653.GH11448@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 from me too, for the record. Martin. At 15:59 06/09/08, Peter Constable wrote: >> From: John Cowan [mailto:cowan@ccil.org] > > >> I'd like to propose a deviation from the proposed rules for languages >> encompassed by a macrolanguage... > >> Just wanted to get that on record. > >+1 (I've had this assumption in the back of my mind all along, but it did >need to be stated explicitly at some point.) > > > >Peter Constable #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 12:11:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMoO5-0002Bc-2K; Mon, 11 Sep 2006 12:11:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMoO3-0002Au-P2 for ltru@ietf.org; Mon, 11 Sep 2006 12:11:55 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMoO2-0002dp-2v for ltru@ietf.org; Mon, 11 Sep 2006 12:11:55 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8BGBrbY008201 for ; Tue, 12 Sep 2006 01:11:53 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 0dc6_3cf42418_41b0_11db_82d7_0014221fa3c9; Tue, 12 Sep 2006 01:11:53 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:59222) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 12 Sep 2006 01:11:57 +0900 Message-Id: <6.0.0.20.2.20060911185558.03e5e9c0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 11 Sep 2006 18:56:48 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Comments that refer to "ISO codes" In-Reply-To: <05d001c6d560$8409f6a0$6401a8c0@DGBP7M81> References: <05d001c6d560$8409f6a0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Do codes sometimes move from 639-3 to 639-2? In that case, it would mean we have to update the comment, which looks like unnecessary work to me. Regards, Martin. At 14:09 06/09/11, Doug Ewell wrote: >For certain grandfathered tags that have been deprecated in favor of ISO 639-based tags, we attached a Comments field that indicates the ISO-based nature of the Preferred-Value. (Seems repetitive to me, but that's another story.) Here's an example: > >> Type: grandfathered >> Tag: art-lojban >> Description: Lojban >> Added: 2001-11-11 >> Preferred-Value: jbo >> Deprecated: 2003-09-02 >> Comments: replaced by ISO code jbo > >I propose modifying these comments slightly to indicate *which* ISO standard begat the replacement tag, like this: > >> Comments: replaced by ISO 639-2 code jbo > >For consistency, we would then also add this sort of comment to existing grandfathered tags that become deprecated by one of the new 639-3-based subtags: > >> Type: grandfathered >> Tag: zh-xiang >> Description: Xiang or Hunanese >> Added: 1999-12-18 >> Preferred-Value: zh-hsn >> Deprecated: xxxx-xx-xx >> Comments: replaced by ISO 639-3 code hsn > >Any comments? So to speak? > >-- >Doug Ewell >Fullerton, California, USA >http://users.adelphia.net/~dewell/ >RFC 4645 * UTN #14 > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 12:14:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMoQn-0003SR-Lu; Mon, 11 Sep 2006 12:14:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMoQl-0003S7-Q8 for ltru@ietf.org; Mon, 11 Sep 2006 12:14:43 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMoQk-0002xO-C6 for ltru@ietf.org; Mon, 11 Sep 2006 12:14:43 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id A602F1E1433; Mon, 11 Sep 2006 09:14:39 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Mon, 11 Sep 2006 09:14:40 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EEF1@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Doug Ewell' , LTRU Working Group Subject: RE: [Ltru] Re: Fw: RFC 4645 on Initial Language Subtag Registry Date: Mon, 11 Sep 2006 09:14:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, My two cents - any 800-page I-D is BAD - publishing one is tantamount to saying "don't bother to pay any attention to the output of this WG". Squashing the registry format (which may change again in the RFC464xbis era, perhaps?) into an I-D is an exercise that diverts attention from the content of the prototype registry and issues with that content. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: Sunday, September 10, 2006 10:59 PM > To: LTRU Working Group > Subject: [Ltru] Re: Fw: RFC 4645 on Initial Language Subtag Registry >=20 >=20 > Randy Presuhn wrote: >=20 > > Based on how the last round went, I think the WG's decision=20 > to use an=20 > > internet draft was correct. > > > > I think the WG's decision to publish to send that material=20 > through the=20 > > RFC publication process was also good, inasmuch as it did elicit=20 > > useful comments, and gave us the requisite paper trail to deal with = > > real or imagined procedural problems. >=20 > Fair enough, then. But I don't want to hear any complaints=20 > from others=20 > that an 800-plus-page I-D is too long or unwieldy, or that=20 > writing one=20 > is an exercise in egotism or self-aggrandizement (I don't=20 > remember who=20 > said that last time). >=20 > > I think the final decision to elide the interesting parts=20 > was perhaps=20 > > unfortunate, but also understandable, given the onslaught=20 > the IETF has=20 > > been suffering. >=20 > Actually I thought that had been the plan for many months. =20 > We knew the=20 > real Registry would see many updates and didn't want people=20 > to use the=20 > initial-registry snapshot as a substitute. >=20 > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > RFC 4645 =E2=80=A2 UTN #14 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 --=20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.2/442 - Release Date: = 9/8/2006 =20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 12:43:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMot3-00013E-5g; Mon, 11 Sep 2006 12:43:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMot1-000138-M1 for ltru@ietf.org; Mon, 11 Sep 2006 12:43:55 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMot0-0007UC-Ey for ltru@ietf.org; Mon, 11 Sep 2006 12:43:55 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GMosx-0002fa-T8; Mon, 11 Sep 2006 12:43:51 -0400 Date: Mon, 11 Sep 2006 12:43:51 -0400 To: Martin Duerst Subject: Re: [Ltru] Comments that refer to "ISO codes" Message-ID: <20060911164351.GB9240@ccil.org> References: <05d001c6d560$8409f6a0$6401a8c0@DGBP7M81> <6.0.0.20.2.20060911185558.03e5e9c0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060911185558.03e5e9c0@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > Do codes sometimes move from 639-3 to 639-2? In that case, it would > mean we have to update the comment, which looks like unnecessary > work to me. Codes will be sometimes *copied* from 639-3 to 639-2, but no *moves* will take place. 639-2 will become a selection of the most widely useful code elements from 639-3 and the future 639-5 (language collections) Nevertheless I agree that adding this information as a comment isn't very useful. -- There is / One art John Cowan No more / No less http://www.ccil.org/~cowan To do / All things With art- / Lessness -- Piet Hein _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 13:40:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMplF-00083n-3G; Mon, 11 Sep 2006 13:39:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMplD-00083i-64 for ltru@ietf.org; Mon, 11 Sep 2006 13:39:55 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMplB-0000vP-Qz for ltru@ietf.org; Mon, 11 Sep 2006 13:39:55 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8BHdO7v075029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Sep 2006 10:39:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=vMfMhrhIwQ0HSR+3i0KTflf9ZKNRPrzw04gW8bLXvZa3YbG2MhXFjrrHThcSkiKe Message-ID: <45059F4B.90101@yahoo-inc.com> Date: Mon, 11 Sep 2006 10:39:23 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Up-to-date copies of the LSR References: <20060910011429.GA12746@ccil.org> In-Reply-To: <20060910011429.GA12746@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > > I think Doug means not that people should be encouraged to pull the > LSR dynamically, but rather that programs that encapsulate the state of > the LSR (like his Windows version) should be made widely available and > updated fairly regularly, monthly or every two months or whatever. > On the other hand, during a presentation to the W3C last week, they pointed out that a large part of the load on their servers was the (usually pointless) dynamic downloading of DTDs. We should at least consider automated methods in which a server can verify that its copy of the registry is the latest that do not involve pulling the whole file. One way to do this, for example, would be a changelog format: File-Date: 2006-09-11 %% (some record) %% (another record) %% File-Date: 2006-09-07 %% (yet another record) ... Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 13:46:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMprz-0002sq-NY; Mon, 11 Sep 2006 13:46:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMprx-0002ob-UX; Mon, 11 Sep 2006 13:46:53 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMpru-00020C-Ib; Mon, 11 Sep 2006 13:46:53 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=nnS5Tt+Uh+nkzrhiRO1AzjLy6ufmTIFQ42oqcNfaq4qDmTF+wA1XZC2uo30sQMb2; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.5.57] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GMprs-0000ca-06; Mon, 11 Sep 2006 13:46:48 -0400 Message-ID: <002601c6d5ca$b0ebeec0$6501a8c0@oemcomputer> From: "Randy Presuhn" To: , "Disman" , "LTRU Working Group" Date: Mon, 11 Sep 2006 10:49:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7afb305a7abefc7b4f4b0ce96a4c1d013bb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.5.57 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ltru] Fw: Email with attached legal disclaimers X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - An important message from the IETF chair... > From: "IETF Chair" > To: "IETF Announcement list" > Sent: Monday, September 11, 2006 7:27 AM > Subject: Email with attached legal disclaimers > > Sometimes people send IETF email with attached legal disclaimers, > usually inserted automatically by their employer's mail system. > These disclaimers make assertions about confidentiality and may contain > phrases like "If you are not the intended recipient be aware that any > disclosure, copying, distribution or use of the contents of this > information is prohibited." > > You are reminded that IETF contributions are automatically subject > to RFC 3978, which explicitly states in Section 3.2 that: > > Each Contributor agrees that any statement in a Contribution, whether > generated automatically or otherwise, that states or implies that the > Contribution is confidential or subject to any privilege, can be > disregarded for all purposes, and will be of no force or effect. > > Therefore, any such disclaimers attached to IETF email can be ignored > for IETF purposes. > > However, we strongly advise all participants to take all possible > steps to prevent the addition of such disclaimers. Among other issues, > some other standards organizations will refuse to consider any liaison > message from an IETF source that contains such a disclaimer. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 13:49:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMpuh-00045J-5j; Mon, 11 Sep 2006 13:49:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMpuf-00045B-Q2 for ltru@ietf.org; Mon, 11 Sep 2006 13:49:41 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMpue-0002PN-JB for ltru@ietf.org; Mon, 11 Sep 2006 13:49:41 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GMpue-0004kT-7W; Mon, 11 Sep 2006 13:49:40 -0400 Date: Mon, 11 Sep 2006 13:49:40 -0400 To: Addison Phillips Subject: Re: [Ltru] Up-to-date copies of the LSR Message-ID: <20060911174940.GE9240@ccil.org> References: <20060910011429.GA12746@ccil.org> <45059F4B.90101@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45059F4B.90101@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > One way to do this, for example, would be a changelog format: That will certainly work, but I can think of two simpler approaches, both of which can be used concurrently, that strike me as just about as good: 1) Provide the File-Date of the current registry as a separate resource with its own URI as well as in the current registry resource. Then you can pull the little resource and only pull the big one if warranted. 2) If you are writing a client that does dynamic pulls, use the HTTP If-Modified-Since: header to avoid pulling unchanged versions. -- John Cowan http://www.ccil.org/~cowan Today an interactive brochure website, tomorrow a global content management system that leverages collective synergy to drive "outside of the box" thinking and formulate key objectives into a win-win game plan with a quality-driven approach that focuses on empowering key players to drive-up their core competencies and increase expectations with an all-around initiative to drive up the bottom-line. --Alex Papadimoulis _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 13:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMq4X-0000GV-3S; Mon, 11 Sep 2006 13:59:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMq4V-0000EQ-LL for ltru@lists.ietf.org; Mon, 11 Sep 2006 13:59:51 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMq4U-0003MS-CN for ltru@lists.ietf.org; Mon, 11 Sep 2006 13:59:51 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GMq4D-00064F-EL for ltru@lists.ietf.org; Mon, 11 Sep 2006 19:59:33 +0200 Received: from pd9fbad3c.dip0.t-ipconnect.de ([217.251.173.60]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Sep 2006 19:59:33 +0200 Received: from nobody by pd9fbad3c.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Sep 2006 19:59:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 11 Sep 2006 19:58:38 +0200 Organization: Lines: 16 Message-ID: <4505A3CE.90F@xyzzy.claranet.de> References: <20060910011429.GA12746@ccil.org> <45059F4B.90101@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad3c.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] Re: Up-to-date copies of the LSR X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > One way to do this, for example, would be a changelog format Another is sending a HEAD request to the IANA server, answer: HTTP/1.1 200 OK Date: Mon, 11 Sep 2006 17:56:21 GMT Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) Last-Modified: Tue, 29 Aug 2006 21:44:40 GMT ETag: "101fb7-141dc-44f4b548" Accept-Ranges: bytes Content-Length: 82396 Connection: close Content-Type: text/plain _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 14:31:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMqZX-0006Kc-49; Mon, 11 Sep 2006 14:31:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMqZW-0006KF-DR; Mon, 11 Sep 2006 14:31:54 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMqZP-0000yk-Gc; Mon, 11 Sep 2006 14:31:54 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8BIVWdp073842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Sep 2006 11:31:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject:content-type; b=ejVNxmIj9go+YqGi4AoZ7tRg1imyiPXPVZejGnxV7r2AOGJyJzROjJ+2ClIsDw2d Message-ID: <4505AB84.9040506@yahoo-inc.com> Date: Mon, 11 Sep 2006 11:31:32 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: internet-drafts@ietf.org Content-Type: multipart/mixed; boundary="------------020308070902060903090709" X-Spam-Score: -14.6 (--------------) X-Scan-Signature: a63e78ed22ecc7cc17fccb299a259960 Cc: 'LTRU Working Group' Subject: [Ltru] submission: draft-ietf-ltru-4646bis, version 0 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --------------020308070902060903090709 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear Editor, Please find attached draft-00, approved by Randy Presuhn, co-chair of the LTRU Working Group, of draft-ietf-ltru-4646bis. Best Regards, Addison (for the editors) -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. --------------020308070902060903090709 Content-Type: text/plain; name="draft-ietf-ltru-4646bis-00.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="draft-ietf-ltru-4646bis-00.txt" CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBLiBQaGlsbGlwcywgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBZYWhvbyEgSW5jLgpPYnNvbGV0ZXM6IDQ2 NDYgKGlmIGFwcHJvdmVkKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE0uIERhdmlz LCBFZC4KRXhwaXJlczogTWFyY2ggMTUsIDIwMDcgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgR29vZ2xlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFNlcHRlbWJlciAxMSwgMjAwNgoKCiAgICAgICAg ICAgICAgICAgICAgIFRhZ3MgZm9yIElkZW50aWZ5aW5nIExhbmd1YWdlcwogICAgICAgICAg ICAgICAgICAgICAgIGRyYWZ0LWlldGYtbHRydS00NjQ2YmlzLTAwCgpTdGF0dXMgb2YgdGhp cyBNZW1vCgogICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0 aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkKICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIg SVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUKICAgaGF2ZSBiZWVuIG9y IHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVz CiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlv biA2IG9mIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVu dHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBp dHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQKICAgb3RoZXIg Z3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJu ZXQtCiAgIERyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRz IHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0 ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQog ICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFz IHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAi d29yayBpbiBwcm9ncmVzcy4iCgogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURy YWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFp ZC1hYnN0cmFjdHMudHh0LgoKICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93 IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3Jn L3NoYWRvdy5odG1sLgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBN YXJjaCAxNSwgMjAwNy4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoQykgVGhl IEludGVybmV0IFNvY2lldHkgKDIwMDYpLgoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIHRoZSBzdHJ1Y3R1cmUsIGNvbnRlbnQsIGNvbnN0cnVjdGlvbiwgYW5kCiAg IHNlbWFudGljcyBvZiBsYW5ndWFnZSB0YWdzIGZvciB1c2UgaW4gY2FzZXMgd2hlcmUgaXQg aXMgZGVzaXJhYmxlIHRvCiAgIGluZGljYXRlIHRoZSBsYW5ndWFnZSB1c2VkIGluIGFuIGlu Zm9ybWF0aW9uIG9iamVjdC4gIEl0IGFsc28KICAgZGVzY3JpYmVzIGhvdyB0byByZWdpc3Rl ciB2YWx1ZXMgZm9yIHVzZSBpbiBsYW5ndWFnZSB0YWdzIGFuZCB0aGUKICAgY3JlYXRpb24g b2YgdXNlci1kZWZpbmVkIGV4dGVuc2lvbnMgZm9yIHByaXZhdGUgaW50ZXJjaGFuZ2UuCgoK CgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMTUsIDIwMDcgICAg ICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxh bmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA2CgoKVGFibGUgb2Yg Q29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAyLiAgVGhlIExhbmd1YWdlIFRhZyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgICAy LjEuICBTeW50YXggLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA0CiAgICAgMi4yLiAgTGFuZ3VhZ2UgU3VidGFnIFNvdXJjZXMgYW5kIElu dGVycHJldGF0aW9uIC4gLiAuIC4gLiAuIC4gLiAgNgogICAgICAgMi4yLjEuICBQcmltYXJ5 IExhbmd1YWdlIFN1YnRhZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgKICAg ICAgIDIuMi4yLiAgRXh0ZW5kZWQgTGFuZ3VhZ2UgU3VidGFncyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDEwCiAgICAgICAyLjIuMy4gIFNjcmlwdCBTdWJ0YWcgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAgICAgMi4yLjQuICBSZWdp b24gU3VidGFnICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEK ICAgICAgIDIuMi41LiAgVmFyaWFudCBTdWJ0YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDEzCiAgICAgICAyLjIuNi4gIEV4dGVuc2lvbiBTdWJ0YWdzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNAogICAgICAgMi4yLjcuICBQ cml2YXRlIFVzZSBTdWJ0YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTYKICAgICAgIDIuMi44LiAgR3JhbmRmYXRoZXJlZCBSZWdpc3RyYXRpb25zICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDE2CiAgICAgICAyLjIuOS4gIENsYXNzZXMgb2YgQ29uZm9y bWFuY2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNwogICAzLiAgUmVnaXN0 cnkgRm9ybWF0IGFuZCBNYWludGVuYW5jZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTgKICAgICAzLjEuICBGb3JtYXQgb2YgdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJl Z2lzdHJ5ICAuIC4gLiAuIC4gLiAuIDE4CiAgICAgMy4yLiAgTGFuZ3VhZ2UgU3VidGFnIFJl dmlld2VyIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMwogICAgIDMuMy4g IE1haW50ZW5hbmNlIG9mIHRoZSBSZWdpc3RyeSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMjQKICAgICAzLjQuICBTdGFiaWxpdHkgb2YgSUFOQSBSZWdpc3RyeSBFbnRyaWVz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI1CiAgICAgMy41LiAgUmVnaXN0cmF0aW9uIFBy b2NlZHVyZSBmb3IgU3VidGFncyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOQogICAgIDMu Ni4gIFBvc3NpYmlsaXRpZXMgZm9yIFJlZ2lzdHJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMzIKICAgICAzLjcuICBFeHRlbnNpb25zIGFuZCBFeHRlbnNpb25zIFJlZ2lz dHJ5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM0CiAgICAgMy44LiAgVXBkYXRlIG9mIHRo ZSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgLiAuIC4gLiAuIC4gLiAuIC4gLiAzNwogICA0 LiAgRm9ybWF0aW9uIGFuZCBQcm9jZXNzaW5nIG9mIExhbmd1YWdlIFRhZ3MgIC4gLiAuIC4g LiAuIC4gLiAuIC4gMzgKICAgICA0LjEuICBDaG9pY2Ugb2YgTGFuZ3VhZ2UgVGFnIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM4CiAgICAgNC4yLiAgTWVhbmluZyBv ZiB0aGUgTGFuZ3VhZ2UgVGFnICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MAog ICAgIDQuMy4gIExlbmd0aCBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gNDEKICAgICAgIDQuMy4xLiAgV29ya2luZyB3aXRoIExpbWl0ZWQg QnVmZmVyIFNpemVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIDQxCiAgICAgICA0LjMuMi4gIFRy dW5jYXRpb24gb2YgTGFuZ3VhZ2UgVGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0 MwogICAgIDQuNC4gIENhbm9uaWNhbGl6YXRpb24gb2YgTGFuZ3VhZ2UgVGFncyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNDMKICAgICA0LjUuICBDb25zaWRlcmF0aW9ucyBmb3IgUHJp dmF0ZSBVc2UgU3VidGFncyAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ1CiAgIDUuICBJQU5BIENv bnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA0NwogICAgIDUuMS4gIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gNDcKICAgICA1LjIuICBFeHRlbnNpb25zIFJlZ2lzdHJ5 ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ3CiAgIDYuICBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA0OQogICA3LiAgQ2hhcmFjdGVyIFNldCBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTAKICAgOC4gIENoYW5nZXMgZnJvbSBSRkMgNDY0 NiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUxCiAgIDkuICBS ZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA1MgogICAgIDkuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTIKICAgICA5LjIuICBJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUzCiAgIEFw cGVuZGl4IEEuICBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA1NQogICBBcHBlbmRpeCBCLiAgRXhhbXBsZXMgb2YgTGFuZ3VhZ2UgVGFn cyAoSW5mb3JtYXRpdmUpIC4gLiAuIC4gLiAuIC4gNTYKICAgQXV0aG9ycycgQWRkcmVzc2Vz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU5CiAg IEludGVsbGVjdHVhbCBQcm9wZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4g LiAuIC4gLiAuIC4gLiA2MAoKCgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJl cyBNYXJjaCAxNSwgMjAwNyAgICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVt YmVyIDIwMDYKCgoxLiAgSW50cm9kdWN0aW9uCgogICBIdW1hbiBiZWluZ3Mgb24gb3VyIHBs YW5ldCBoYXZlLCBwYXN0IGFuZCBwcmVzZW50LCB1c2VkIGEgbnVtYmVyIG9mCiAgIGxhbmd1 YWdlcy4gIFRoZXJlIGFyZSBtYW55IHJlYXNvbnMgd2h5IG9uZSB3b3VsZCB3YW50IHRvIGlk ZW50aWZ5IHRoZQogICBsYW5ndWFnZSB1c2VkIHdoZW4gcHJlc2VudGluZyBvciByZXF1ZXN0 aW5nIGluZm9ybWF0aW9uLgoKICAgQSB1c2VyJ3MgbGFuZ3VhZ2UgcHJlZmVyZW5jZXMgb2Z0 ZW4gbmVlZCB0byBiZSBpZGVudGlmaWVkIHNvIHRoYXQKICAgYXBwcm9wcmlhdGUgcHJvY2Vz c2luZyBjYW4gYmUgYXBwbGllZC4gIEZvciBleGFtcGxlLCB0aGUgdXNlcidzCiAgIGxhbmd1 YWdlIHByZWZlcmVuY2VzIGluIGEgV2ViIGJyb3dzZXIgY2FuIGJlIHVzZWQgdG8gc2VsZWN0 IFdlYiBwYWdlcwogICBhcHByb3ByaWF0ZWx5LiAgTGFuZ3VhZ2UgcHJlZmVyZW5jZXMgY2Fu IGFsc28gYmUgdXNlZCB0byBzZWxlY3QgYW1vbmcKICAgdG9vbHMgKHN1Y2ggYXMgZGljdGlv bmFyaWVzKSB0byBhc3Npc3QgaW4gdGhlIHByb2Nlc3Npbmcgb3IKICAgdW5kZXJzdGFuZGlu ZyBvZiBjb250ZW50IGluIGRpZmZlcmVudCBsYW5ndWFnZXMuCgogICBJbiBhZGRpdGlvbiwg a25vd2xlZGdlIGFib3V0IHRoZSBwYXJ0aWN1bGFyIGxhbmd1YWdlIHVzZWQgYnkgc29tZQog ICBwaWVjZSBvZiBpbmZvcm1hdGlvbiBjb250ZW50IG1pZ2h0IGJlIHVzZWZ1bCBvciBldmVu IHJlcXVpcmVkIGJ5IHNvbWUKICAgdHlwZXMgb2YgcHJvY2Vzc2luZzsgZm9yIGV4YW1wbGUs IHNwZWxsLWNoZWNraW5nLCBjb21wdXRlci0KICAgc3ludGhlc2l6ZWQgc3BlZWNoLCBCcmFp bGxlIHRyYW5zY3JpcHRpb24sIG9yIGhpZ2gtcXVhbGl0eSBwcmludAogICByZW5kZXJpbmdz LgoKICAgT25lIG1lYW5zIG9mIGluZGljYXRpbmcgdGhlIGxhbmd1YWdlIHVzZWQgaXMgYnkg bGFiZWxpbmcgdGhlCiAgIGluZm9ybWF0aW9uIGNvbnRlbnQgd2l0aCBhbiBpZGVudGlmaWVy IG9yICJ0YWciLiAgVGhlc2UgdGFncyBjYW4gYmUKICAgdXNlZCB0byBzcGVjaWZ5IHVzZXIg cHJlZmVyZW5jZXMgd2hlbiBzZWxlY3RpbmcgaW5mb3JtYXRpb24gY29udGVudCwKICAgb3Ig Zm9yIGxhYmVsaW5nIGFkZGl0aW9uYWwgYXR0cmlidXRlcyBvZiBjb250ZW50IGFuZCBhc3Nv Y2lhdGVkCiAgIHJlc291cmNlcy4KCiAgIFRhZ3MgY2FuIGFsc28gYmUgdXNlZCB0byBpbmRp Y2F0ZSBhZGRpdGlvbmFsIGxhbmd1YWdlIGF0dHJpYnV0ZXMgb2YKICAgY29udGVudC4gIEZv ciBleGFtcGxlLCBpbmRpY2F0aW5nIHNwZWNpZmljIGluZm9ybWF0aW9uIGFib3V0IHRoZQog ICBkaWFsZWN0LCB3cml0aW5nIHN5c3RlbSwgb3Igb3J0aG9ncmFwaHkgdXNlZCBpbiBhIGRv Y3VtZW50IG9yCiAgIHJlc291cmNlIG1heSBlbmFibGUgdGhlIHVzZXIgdG8gb2J0YWluIGlu Zm9ybWF0aW9uIGluIGEgZm9ybSB0aGF0CiAgIHRoZXkgY2FuIHVuZGVyc3RhbmQsIG9yIGl0 IGNhbiBiZSBpbXBvcnRhbnQgaW4gcHJvY2Vzc2luZyBvcgogICByZW5kZXJpbmcgdGhlIGdp dmVuIGNvbnRlbnQgaW50byBhbiBhcHByb3ByaWF0ZSBmb3JtIG9yIHN0eWxlLgoKICAgVGhp cyBkb2N1bWVudCBzcGVjaWZpZXMgYSBwYXJ0aWN1bGFyIGlkZW50aWZpZXIgbWVjaGFuaXNt ICh0aGUKICAgbGFuZ3VhZ2UgdGFnKSBhbmQgYSByZWdpc3RyYXRpb24gZnVuY3Rpb24gZm9y IHZhbHVlcyB0byBiZSB1c2VkIHRvCiAgIGZvcm0gdGFncy4gIEl0IGFsc28gZGVmaW5lcyBh IG1lY2hhbmlzbSBmb3IgcHJpdmF0ZSB1c2UgdmFsdWVzIGFuZAogICBmdXR1cmUgZXh0ZW5z aW9uLgoKICAgVGhpcyBkb2N1bWVudCByZXBsYWNlcyBbUkZDNDY0Nl0sIHdoaWNoIHJlcGxh Y2VkIFtSRkMzMDY2XS4gIEZvciBhCiAgIGxpc3Qgb2YgY2hhbmdlcyBpbiB0aGlzIGRvY3Vt ZW50LCBzZWUgU2VjdGlvbiA4LgoKICAgVGhlIGtleXdvcmRzICJNVVNUIiwgIk1VU1QgTk9U IiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hP VUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlz CiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JG QzIxMTldLgoKCgoKCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNo IDE1LCAyMDA3ICAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAw NgoKCjIuICBUaGUgTGFuZ3VhZ2UgVGFnCgogICBMYW5ndWFnZSB0YWdzIGFyZSB1c2VkIHRv IGhlbHAgaWRlbnRpZnkgbGFuZ3VhZ2VzLCB3aGV0aGVyIHNwb2tlbiwKICAgd3JpdHRlbiwg c2lnbmVkLCBvciBvdGhlcndpc2Ugc2lnbmFsZWQsIGZvciB0aGUgcHVycG9zZSBvZgogICBj b21tdW5pY2F0aW9uLiAgVGhpcyBpbmNsdWRlcyBjb25zdHJ1Y3RlZCBhbmQgYXJ0aWZpY2lh bCBsYW5ndWFnZXMsCiAgIGJ1dCBleGNsdWRlcyBsYW5ndWFnZXMgbm90IGludGVuZGVkIHBy aW1hcmlseSBmb3IgaHVtYW4KICAgY29tbXVuaWNhdGlvbiwgc3VjaCBhcyBwcm9ncmFtbWlu ZyBsYW5ndWFnZXMuCgoyLjEuICBTeW50YXgKCiAgIFRoZSBsYW5ndWFnZSB0YWcgaXMgY29t cG9zZWQgb2Ygb25lIG9yIG1vcmUgcGFydHMsIGtub3duIGFzCiAgICJzdWJ0YWdzIi4gIEVh Y2ggc3VidGFnIGNvbnNpc3RzIG9mIGEgc2VxdWVuY2Ugb2YgYWxwaGFudW1lcmljCiAgIGNo YXJhY3RlcnMuICBTdWJ0YWdzIGFyZSBkaXN0aW5ndWlzaGVkIGFuZCBzZXBhcmF0ZWQgZnJv bSBvbmUgYW5vdGhlcgogICBieSBhIGh5cGhlbiAoIi0iLCBBQk5GIFtSRkM0MjM0XSAleDJE KS4gIEEgbGFuZ3VhZ2UgdGFnIGNvbnNpc3RzIG9mIGEKICAgInByaW1hcnkgbGFuZ3VhZ2Ui IHN1YnRhZyBhbmQgYSAocG9zc2libHkgZW1wdHkpIHNlcmllcyBvZiBzdWJzZXF1ZW50CiAg IHN1YnRhZ3MsIGVhY2ggb2Ygd2hpY2ggcmVmaW5lcyBvciBuYXJyb3dzIHRoZSByYW5nZSBv ZiBsYW5ndWFnZXMKICAgaWRlbnRpZmllZCBieSB0aGUgb3ZlcmFsbCB0YWcuCgogICBVc3Vh bGx5LCBlYWNoIHR5cGUgb2Ygc3VidGFnIGlzIGRpc3Rpbmd1aXNoZWQgYnkgbGVuZ3RoLCBw b3NpdGlvbiBpbgogICB0aGUgdGFnLCBhbmQgY29udGVudDogc3VidGFncyBjYW4gYmUgcmVj b2duaXplZCBzb2xlbHkgYnkgdGhlc2UKICAgZmVhdHVyZXMuICBUaGUgb25seSBleGNlcHRp b24gdG8gdGhpcyBpcyBhIGZpeGVkIGxpc3Qgb2YKICAgZ3JhbmRmYXRoZXJlZCB0YWdzIHJl Z2lzdGVyZWQgdW5kZXIgUkZDIDMwNjYgW1JGQzMwNjZdLiAgVGhpcyBtYWtlcwogICBpdCBw b3NzaWJsZSB0byBjb25zdHJ1Y3QgYSBwYXJzZXIgdGhhdCBjYW4gZXh0cmFjdCBhbmQgYXNz aWduIHNvbWUKICAgc2VtYW50aWMgaW5mb3JtYXRpb24gdG8gdGhlIHN1YnRhZ3MsIGV2ZW4g aWYgdGhlIHNwZWNpZmljIHN1YnRhZwogICB2YWx1ZXMgYXJlIG5vdCByZWNvZ25pemVkLiAg VGh1cywgYSBwYXJzZXIgbmVlZCBub3QgaGF2ZSBhbiB1cC10by0KICAgZGF0ZSBjb3B5IChv ciBhbnkgY29weSBhdCBhbGwpIG9mIHRoZSBzdWJ0YWcgcmVnaXN0cnkgdG8gcGVyZm9ybSBt b3N0CiAgIHNlYXJjaGluZyBhbmQgbWF0Y2hpbmcgb3BlcmF0aW9ucy4KCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMTUs IDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA2CgoK ICAgVGhlIHN5bnRheCBvZiB0aGUgbGFuZ3VhZ2UgdGFnIGluIEFCTkYgW1JGQzQyMzRdIGlz OgoKICAgTGFuZ3VhZ2UtVGFnICA9IGxhbmd0YWcKICAgICAgICAgICAgICAgICAvIHByaXZh dGV1c2UgICAgICAgICAgICAgOyBwcml2YXRlIHVzZSB0YWcKICAgICAgICAgICAgICAgICAv IGdyYW5kZmF0aGVyZWQgICAgICAgICAgOyBncmFuZGZhdGhlcmVkIHJlZ2lzdHJhdGlvbnMK CiAgIGxhbmd0YWcgICAgICAgPSAobGFuZ3VhZ2UKICAgICAgICAgICAgICAgICAgICBbIi0i IHNjcmlwdF0KICAgICAgICAgICAgICAgICAgICBbIi0iIHJlZ2lvbl0KICAgICAgICAgICAg ICAgICAgICAqKCItIiB2YXJpYW50KQogICAgICAgICAgICAgICAgICAgICooIi0iIGV4dGVu c2lvbikKICAgICAgICAgICAgICAgICAgICBbIi0iIHByaXZhdGV1c2VdKQoKICAgbGFuZ3Vh Z2UgICAgICA9ICgyKjNBTFBIQSBbIGV4dGxhbmcgXSkgOyBzaG9ydGVzdCBJU08gNjM5IGNv ZGUKICAgICAgICAgICAgICAgICAvIDRBTFBIQSAgICAgICAgICAgICAgICAgOyByZXNlcnZl ZCBmb3IgZnV0dXJlIHVzZQogICAgICAgICAgICAgICAgIC8gNSo4QUxQSEEgICAgICAgICAg ICAgICA7IHJlZ2lzdGVyZWQgbGFuZ3VhZ2Ugc3VidGFnCgogICBleHRsYW5nICAgICAgID0g KjMoIi0iIDNBTFBIQSkgICAgICAgICA7IHNwZWNpZmljIElTTyA2MzktMyBjb2RlcwoKICAg c2NyaXB0ICAgICAgICA9IDRBTFBIQSAgICAgICAgICAgICAgICAgOyBJU08gMTU5MjQgY29k ZQoKICAgcmVnaW9uICAgICAgICA9IDJBTFBIQSAgICAgICAgICAgICAgICAgOyBJU08gMzE2 NiBjb2RlCiAgICAgICAgICAgICAgICAgLyAzRElHSVQgICAgICAgICAgICAgICAgIDsgVU4g TS40OSBjb2RlCgogICB2YXJpYW50ICAgICAgID0gNSo4YWxwaGFudW0gICAgICAgICAgICA7 IHJlZ2lzdGVyZWQgdmFyaWFudHMKICAgICAgICAgICAgICAgICAvIChESUdJVCAzYWxwaGFu dW0pCgogICBleHRlbnNpb24gICAgID0gc2luZ2xldG9uIDEqKCItIiAoMio4YWxwaGFudW0p KQoKICAgc2luZ2xldG9uICAgICA9ICV4NDEtNTcgLyAleDU5LTVBIC8gJXg2MS03NyAvICV4 NzktN0EgLyBESUdJVAogICAgICAgICAgICAgICAgIDsgImEiLSJ3IiAvICJ5Ii0ieiIgLyAi QSItIlciIC8gIlkiLSJaIiAvICIwIi0iOSIKICAgICAgICAgICAgICAgICA7IFNpbmdsZSBs ZXR0ZXJzOiB4L1ggaXMgcmVzZXJ2ZWQgZm9yIHByaXZhdGUgdXNlCgogICBwcml2YXRldXNl ICAgID0gKCJ4Ii8iWCIpIDEqKCItIiAoMSo4YWxwaGFudW0pKQoKICAgZ3JhbmRmYXRoZXJl ZCA9IDEqM0FMUEhBIDEqMigiLSIgKDIqOGFscGhhbnVtKSkKICAgICAgICAgICAgICAgICAg IDsgZ3JhbmRmYXRoZXJlZCByZWdpc3RyYXRpb24KICAgICAgICAgICAgICAgICAgIDsgTm90 ZTogaSBpcyB0aGUgb25seSBzaW5nbGV0b24KICAgICAgICAgICAgICAgICAgIDsgdGhhdCBz dGFydHMgYSBncmFuZGZhdGhlcmVkIHRhZwoKICAgYWxwaGFudW0gICAgICA9IChBTFBIQSAv IERJR0lUKSAgICAgICA7IGxldHRlcnMgYW5kIG51bWJlcnMKCiAgIEZpZ3VyZSAxOiBMYW5n dWFnZSBUYWcgQUJORgoKICAgTm90ZTogVGhlcmUgaXMgYSBzdWJ0bGV0eSBpbiB0aGUgQUJO RiBmb3IgJ3ZhcmlhbnQnOiB2YXJpYW50cwogICBzdGFydGluZyB3aXRoIGEgZGlnaXQgTUFZ IGJlIGZvdXIgY2hhcmFjdGVycyBsb25nLCB3aGlsZSB0aG9zZQogICBzdGFydGluZyB3aXRo IGEgbGV0dGVyIE1VU1QgYmUgYXQgbGVhc3QgZml2ZSBjaGFyYWN0ZXJzIGxvbmcuCgoKCgpQ aGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAxNSwgMjAwNyAgICAgICAg ICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3Rh Z3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDYKCgogICBBbGwgc3VidGFn cyBoYXZlIGEgbWF4aW11bSBsZW5ndGggb2YgZWlnaHQgY2hhcmFjdGVycyBhbmQgd2hpdGVz cGFjZQogICBpcyBub3QgcGVybWl0dGVkIGluIGEgbGFuZ3VhZ2UgdGFnLiAgRm9yIGV4YW1w bGVzIG9mIGxhbmd1YWdlIHRhZ3MsCiAgIHNlZSBBcHBlbmRpeCBCLgoKICAgTm90ZSB0aGF0 IGFsdGhvdWdoIFtSRkM0MjM0XSByZWZlcnMgdG8gb2N0ZXRzLCB0aGUgbGFuZ3VhZ2UgdGFn cwogICBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBhcmUgc2VxdWVuY2VzIG9mIGNoYXJh Y3RlcnMgZnJvbSB0aGUgVVMtCiAgIEFTQ0lJIFtJU082NDZdIHJlcGVydG9pcmUuICBMYW5n dWFnZSB0YWdzIE1BWSBiZSB1c2VkIGluIGRvY3VtZW50cwogICBhbmQgYXBwbGljYXRpb25z IHRoYXQgdXNlIG90aGVyIGVuY29kaW5ncywgc28gbG9uZyBhcyB0aGVzZSBlbmNvbXBhc3MK ICAgdGhlIFVTLUFTQ0lJIHJlcGVydG9pcmUuICBBbiBleGFtcGxlIG9mIHRoaXMgd291bGQg YmUgYW4gWE1MIGRvY3VtZW50CiAgIHRoYXQgdXNlcyB0aGUgVVRGLTE2TEUgW1JGQzI3ODFd IGVuY29kaW5nIG9mIFtVbmljb2RlXS4KCiAgIFRoZSB0YWdzIGFuZCB0aGVpciBzdWJ0YWdz LCBpbmNsdWRpbmcgcHJpdmF0ZSB1c2UgYW5kIGV4dGVuc2lvbnMsIGFyZQogICB0byBiZSB0 cmVhdGVkIGFzIGNhc2UgaW5zZW5zaXRpdmU6IHRoZXJlIGV4aXN0IGNvbnZlbnRpb25zIGZv ciB0aGUKICAgY2FwaXRhbGl6YXRpb24gb2Ygc29tZSBvZiB0aGUgc3VidGFncywgYnV0IHRo ZXNlIE1VU1QgTk9UIGJlIHRha2VuIHRvCiAgIGNhcnJ5IG1lYW5pbmcuCgogICBGb3IgZXhh bXBsZToKCiAgIG8gIFtJU082MzktMV0gcmVjb21tZW5kcyB0aGF0IGxhbmd1YWdlIGNvZGVz IGJlIHdyaXR0ZW4gaW4gbG93ZXJjYXNlCiAgICAgICgnbW4nIE1vbmdvbGlhbikuCgogICBv ICBbSVNPMzE2Ni0xXSByZWNvbW1lbmRzIHRoYXQgY291bnRyeSBjb2RlcyBiZSBjYXBpdGFs aXplZCAoJ01OJwogICAgICBNb25nb2xpYSkuCgogICBvICBbSVNPMTU5MjRdIHJlY29tbWVu ZHMgdGhhdCBzY3JpcHQgY29kZXMgdXNlIGxvd2VyY2FzZSB3aXRoIHRoZQogICAgICBpbml0 aWFsIGxldHRlciBjYXBpdGFsaXplZCAoJ0N5cmwnIEN5cmlsbGljKS4KCiAgIEhvd2V2ZXIs IGluIHRoZSB0YWdzIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudCwgdGhlIHVwcGVyY2FzZSBV Uy1BU0NJSQogICBsZXR0ZXJzIGluIHRoZSByYW5nZSAnQScgdGhyb3VnaCAnWicgYXJlIGNv bnNpZGVyZWQgZXF1aXZhbGVudCBhbmQKICAgbWFwcGVkIGRpcmVjdGx5IHRvIHRoZWlyIFVT LUFTQ0lJIGxvd2VyY2FzZSBlcXVpdmFsZW50cyBpbiB0aGUgcmFuZ2UKICAgJ2EnIHRocm91 Z2ggJ3onLiAgVGh1cywgdGhlIHRhZyAibW4tQ3lybC1NTiIgaXMgbm90IGRpc3RpbmN0IGZy b20KICAgIk1OLWNZUkwtbW4iIG9yICJtTi1jWXJMLU1uIiAob3IgYW55IG90aGVyIGNvbWJp bmF0aW9uKSwgYW5kIGVhY2ggb2YKICAgdGhlc2UgdmFyaWF0aW9ucyBjb252ZXlzIHRoZSBz YW1lIG1lYW5pbmc6IE1vbmdvbGlhbiB3cml0dGVuIGluIHRoZQogICBDeXJpbGxpYyBzY3Jp cHQgYXMgdXNlZCBpbiBNb25nb2xpYS4KCiAgIEFsdGhvdWdoIGNhc2UgZGlzdGluY3Rpb25z IGRvIG5vdCBjYXJyeSBtZWFuaW5nIGluIGxhbmd1YWdlIHRhZ3MsCiAgIGNvbnNpc3RlbnQg Zm9ybWF0dGluZyBhbmQgcHJlc2VudGF0aW9uIG9mIHRoZSB0YWdzIHdpbGwgYWlkIHVzZXJz LgogICBUaGUgZm9ybWF0IG9mIHRoZSB0YWdzIGFuZCBzdWJ0YWdzIGluIHRoZSByZWdpc3Ry eSBpcyBSRUNPTU1FTkRFRC4KICAgSW4gdGhpcyBmb3JtYXQsIGFsbCBub24taW5pdGlhbCB0 d28tbGV0dGVyIHN1YnRhZ3MgYXJlIHVwcGVyY2FzZSwgYWxsCiAgIG5vbi1pbml0aWFsIGZv dXItbGV0dGVyIHN1YnRhZ3MgYXJlIHRpdGxlY2FzZSwgYW5kIGFsbCBvdGhlciBzdWJ0YWdz CiAgIGFyZSBsb3dlcmNhc2UuCgoyLjIuICBMYW5ndWFnZSBTdWJ0YWcgU291cmNlcyBhbmQg SW50ZXJwcmV0YXRpb24KCiAgIFRoZSBuYW1lc3BhY2Ugb2YgbGFuZ3VhZ2UgdGFncyBhbmQg dGhlaXIgc3VidGFncyBpcyBhZG1pbmlzdGVyZWQgYnkKICAgdGhlIEludGVybmV0IEFzc2ln bmVkIE51bWJlcnMgQXV0aG9yaXR5IChJQU5BKSBbUkZDMjg2MF0gYWNjb3JkaW5nIHRvCiAg IHRoZSBydWxlcyBpbiBTZWN0aW9uIDUgb2YgdGhpcyBkb2N1bWVudC4gIFRoZSBMYW5ndWFn ZSBTdWJ0YWcKICAgUmVnaXN0cnkgbWFpbnRhaW5lZCBieSBJQU5BIGlzIHRoZSBzb3VyY2Ug Zm9yIHZhbGlkIHN1YnRhZ3M6IG90aGVyCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBF eHBpcmVzIE1hcmNoIDE1LCAyMDA3ICAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICBT ZXB0ZW1iZXIgMjAwNgoKCiAgIHN0YW5kYXJkcyByZWZlcmVuY2VkIGluIHRoaXMgc2VjdGlv biBwcm92aWRlIHRoZSBzb3VyY2UgbWF0ZXJpYWwgZm9yCiAgIHRoYXQgcmVnaXN0cnkuCgog ICBUZXJtaW5vbG9neSB1c2VkIGluIHRoaXMgZG9jdW1lbnQ6CgogICBvICBUYWcgb3IgdGFn cyByZWZlcnMgdG8gYSBjb21wbGV0ZSBsYW5ndWFnZSB0YWcsIHN1Y2ggYXMKICAgICAgImZy LUxhdG4tQ0EiLiAgRXhhbXBsZXMgb2YgdGFncyBpbiB0aGlzIGRvY3VtZW50IGFyZSBlbmNs b3NlZCBpbgogICAgICBkb3VibGUtcXVvdGVzICgiZW4tVVMiKS4KCiAgIG8gIFN1YnRhZyBy ZWZlcnMgdG8gYSBzcGVjaWZpYyBzZWN0aW9uIG9mIGEgdGFnLCBkZWxpbWl0ZWQgYnkgaHlw aGVuLAogICAgICBzdWNoIGFzIHRoZSBzdWJ0YWcgJ0xhdG4nIGluICJmci1MYXRuLUNBIi4g IEV4YW1wbGVzIG9mIHN1YnRhZ3MgaW4KICAgICAgdGhpcyBkb2N1bWVudCBhcmUgZW5jbG9z ZWQgaW4gc2luZ2xlIHF1b3RlcyAoJ0xhdG4nKS4KCiAgIG8gIENvZGUgb3IgY29kZXMgcmVm ZXJzIHRvIHZhbHVlcyBkZWZpbmVkIGluIGV4dGVybmFsIHN0YW5kYXJkcyAoYW5kCiAgICAg IHdoaWNoIGFyZSB1c2VkIGFzIHN1YnRhZ3MgaW4gdGhpcyBkb2N1bWVudCkuICBGb3IgZXhh bXBsZSwgJ0xhdG4nCiAgICAgIGlzIGFuIFtJU08xNTkyNF0gc2NyaXB0IGNvZGUgdGhhdCB3 YXMgdXNlZCB0byBkZWZpbmUgdGhlICdMYXRuJwogICAgICBzY3JpcHQgc3VidGFnIGZvciB1 c2UgaW4gYSBsYW5ndWFnZSB0YWcuICBFeGFtcGxlcyBvZiBjb2RlcyBpbgogICAgICB0aGlz IGRvY3VtZW50IGFyZSBlbmNsb3NlZCBpbiBzaW5nbGUgcXVvdGVzICgnZW4nLCAnTGF0bicp LgoKICAgVGhlIGRlZmluaXRpb25zIGluIHRoaXMgc2VjdGlvbiBhcHBseSB0byB0aGUgdmFy aW91cyBzdWJ0YWdzIHdpdGhpbgogICB0aGUgbGFuZ3VhZ2UgdGFncyBkZWZpbmVkIGJ5IHRo aXMgZG9jdW1lbnQsIGV4Y2VwdGluZyB0aG9zZQogICAiZ3JhbmRmYXRoZXJlZCIgdGFncyBk ZWZpbmVkIGluIFNlY3Rpb24gMi4yLjguCgogICBMYW5ndWFnZSB0YWdzIGFyZSBkZXNpZ25l ZCBzbyB0aGF0IGVhY2ggc3VidGFnIHR5cGUgaGFzIHVuaXF1ZSBsZW5ndGgKICAgYW5kIGNv bnRlbnQgcmVzdHJpY3Rpb25zLiAgVGhlc2UgbWFrZSBpZGVudGlmaWNhdGlvbiBvZiB0aGUg c3VidGFnJ3MKICAgdHlwZSBwb3NzaWJsZSwgZXZlbiBpZiB0aGUgY29udGVudCBvZiB0aGUg c3VidGFnIGl0c2VsZiBpcwogICB1bnJlY29nbml6ZWQuICBUaGlzIGFsbG93cyB0YWdzIHRv IGJlIHBhcnNlZCBhbmQgcHJvY2Vzc2VkIHdpdGhvdXQKICAgcmVmZXJlbmNlIHRvIHRoZSBs YXRlc3QgdmVyc2lvbiBvZiB0aGUgdW5kZXJseWluZyBzdGFuZGFyZHMgb3IgdGhlCiAgIElB TkEgcmVnaXN0cnkgYW5kIG1ha2VzIHRoZSBhc3NvY2lhdGVkIGV4Y2VwdGlvbiBoYW5kbGlu ZyB3aGVuCiAgIHBhcnNpbmcgdGFncyBzaW1wbGVyLgoKICAgU3VidGFncyBpbiB0aGUgSUFO QSByZWdpc3RyeSB0aGF0IGRvIG5vdCBjb21lIGZyb20gYW4gdW5kZXJseWluZwogICBzdGFu ZGFyZCBjYW4gb25seSBhcHBlYXIgaW4gc3BlY2lmaWMgcG9zaXRpb25zIGluIGEgdGFnLgog ICBTcGVjaWZpY2FsbHksIHRoZXkgY2FuIG9ubHkgb2NjdXIgYXMgcHJpbWFyeSBsYW5ndWFn ZSBzdWJ0YWdzIG9yIGFzCiAgIHZhcmlhbnQgc3VidGFncy4KCiAgIE5vdGUgdGhhdCBzZXF1 ZW5jZXMgb2YgcHJpdmF0ZSB1c2UgYW5kIGV4dGVuc2lvbiBzdWJ0YWdzIE1VU1Qgb2NjdXIK ICAgYXQgdGhlIGVuZCBvZiB0aGUgc2VxdWVuY2Ugb2Ygc3VidGFncyBhbmQgTVVTVCBOT1Qg YmUgaW50ZXJzcGVyc2VkCiAgIHdpdGggc3VidGFncyBkZWZpbmVkIGVsc2V3aGVyZSBpbiB0 aGlzIGRvY3VtZW50LgoKICAgU2luZ2xlLWxldHRlciBhbmQgc2luZ2xlLWRpZ2l0IHN1YnRh Z3MgYXJlIHJlc2VydmVkIGZvciBjdXJyZW50IG9yCiAgIGZ1dHVyZSB1c2UuICBUaGVzZSBp bmNsdWRlIHRoZSBmb2xsb3dpbmcgY3VycmVudCB1c2VzOgoKICAgbyAgVGhlIHNpbmdsZS1s ZXR0ZXIgc3VidGFnICd4JyBpcyByZXNlcnZlZCB0byBpbnRyb2R1Y2UgYSBzZXF1ZW5jZQog ICAgICBvZiBwcml2YXRlIHVzZSBzdWJ0YWdzLiAgVGhlIGludGVycHJldGF0aW9uIG9mIGFu eSBwcml2YXRlIHVzZQogICAgICBzdWJ0YWdzIGlzIGRlZmluZWQgc29sZWx5IGJ5IHByaXZh dGUgYWdyZWVtZW50IGFuZCBpcyBub3QgZGVmaW5lZAogICAgICBieSB0aGUgcnVsZXMgaW4g dGhpcyBzZWN0aW9uIG9yIGluIGFueSBzdGFuZGFyZCBvciByZWdpc3RyeQogICAgICBkZWZp bmVkIGluIHRoaXMgZG9jdW1lbnQuCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBp cmVzIE1hcmNoIDE1LCAyMDA3ICAgICAgICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0 ZW1iZXIgMjAwNgoKCiAgIG8gIEFsbCBvdGhlciBzaW5nbGUtbGV0dGVyIHN1YnRhZ3MgYXJl IHJlc2VydmVkIHRvIGludHJvZHVjZQogICAgICBzdGFuZGFyZGl6ZWQgZXh0ZW5zaW9uIHN1 YnRhZyBzZXF1ZW5jZXMgYXMgZGVzY3JpYmVkIGluCiAgICAgIFNlY3Rpb24gMy43LgoKICAg VGhlIHNpbmdsZS1sZXR0ZXIgc3VidGFnICdpJyBpcyB1c2VkIGJ5IHNvbWUgZ3JhbmRmYXRo ZXJlZCB0YWdzLCBzdWNoCiAgIGFzICJpLWVub2NoaWFuIiwgd2hlcmUgaXQgYWx3YXlzIGFw cGVhcnMgaW4gdGhlIGZpcnN0IHBvc2l0aW9uIGFuZAogICBjYW5ub3QgYmUgY29uZnVzZWQg d2l0aCBhbiBleHRlbnNpb24uCgoyLjIuMS4gIFByaW1hcnkgTGFuZ3VhZ2UgU3VidGFnCgog ICBUaGUgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgaXMgdGhlIGZpcnN0IHN1YnRhZyBpbiBh IGxhbmd1YWdlIHRhZwogICAod2l0aCB0aGUgZXhjZXB0aW9uIG9mIHByaXZhdGUgdXNlIGFu ZCBjZXJ0YWluIGdyYW5kZmF0aGVyZWQgdGFncykKICAgYW5kIGNhbm5vdCBiZSBvbWl0dGVk LiAgVGhlIGZvbGxvd2luZyBydWxlcyBhcHBseSB0byB0aGUgcHJpbWFyeQogICBsYW5ndWFn ZSBzdWJ0YWc6CgogICAxLiAgQWxsIHR3by1jaGFyYWN0ZXIgcHJpbWFyeSBsYW5ndWFnZSBz dWJ0YWdzIHdlcmUgZGVmaW5lZCBpbiB0aGUKICAgICAgIElBTkEgcmVnaXN0cnkgYWNjb3Jk aW5nIHRvIHRoZSBhc3NpZ25tZW50cyBmb3VuZCBpbiB0aGUgc3RhbmRhcmQKICAgICAgIElT TyA2MzkgUGFydCAxLCAiSVNPIDYzOS0xOjIwMDIsIENvZGVzIGZvciB0aGUgcmVwcmVzZW50 YXRpb24gb2YKICAgICAgIG5hbWVzIG9mIGxhbmd1YWdlcyAtLSBQYXJ0IDE6IEFscGhhLTIg Y29kZSIgW0lTTzYzOS0xXSwgb3IgdXNpbmcKICAgICAgIGFzc2lnbm1lbnRzIHN1YnNlcXVl bnRseSBtYWRlIGJ5IHRoZSBJU08gNjM5IFBhcnQgMSBtYWludGVuYW5jZQogICAgICAgYWdl bmN5IG9yIGdvdmVybmluZyBzdGFuZGFyZGl6YXRpb24gYm9kaWVzLgoKICAgMi4gIEFsbCB0 aHJlZS1jaGFyYWN0ZXIgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzIHdlcmUgZGVmaW5lZCBp biB0aGUKICAgICAgIElBTkEgcmVnaXN0cnkgYWNjb3JkaW5nIHRvIHRoZSBhc3NpZ25tZW50 cyBmb3VuZCBpbiBlaXRoZXIgSVNPCiAgICAgICA2MzkgUGFydCAyLCAiSVNPIDYzOS0yOjE5 OTggLSBDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mCiAgICAgICBuYW1lcyBvZiBs YW5ndWFnZXMgLS0gUGFydCAyOiBBbHBoYS0zIGNvZGUgLSBlZGl0aW9uIDEiCiAgICAgICBb SVNPNjM5LTJdLCBJU08gNjM5IFBhcnQgMywgIklTTyA2MzktMzoyMDA/LCBbWz8/bWlzc2lu ZyBvZmZpY2lhbAogICAgICAgdGl0bGU/P11dIiwgb3IgYXNzaWdubWVudHMgc3Vic2VxdWVu dGx5IG1hZGUgYnkgdGhlIHJlbGV2YW50IElTTwogICAgICAgNjM5IG1haW50ZW5hbmNlIGFn ZW5naWVzIG9yIGdvdmVybmluZyBzdGFuZGFyZGl6YXRpb24gYm9kaWVzLgoKICAgMy4gIFRo ZSBzdWJ0YWdzIGluIHRoZSByYW5nZSAncWFhJyB0aHJvdWdoICdxdHonIGFyZSByZXNlcnZl ZCBmb3IKICAgICAgIHByaXZhdGUgdXNlIGluIGxhbmd1YWdlIHRhZ3MuICBUaGVzZSBzdWJ0 YWdzIGNvcnJlc3BvbmQgdG8gY29kZXMKICAgICAgIHJlc2VydmVkIGJ5IElTTyA2MzktMiBm b3IgcHJpdmF0ZSB1c2UuICBUaGVzZSBjb2RlcyBNQVkgYmUgdXNlZAogICAgICAgZm9yIG5v bi1yZWdpc3RlcmVkIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyAoaW5zdGVhZCBvZiB1c2lu ZwogICAgICAgcHJpdmF0ZSB1c2Ugc3VidGFncyBmb2xsb3dpbmcgJ3gtJykuICBQbGVhc2Ug cmVmZXIgdG8gU2VjdGlvbiA0LjUKICAgICAgIGZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHBy aXZhdGUgdXNlIHN1YnRhZ3MuCgogICA0LiAgQWxsIGZvdXItY2hhcmFjdGVyIGxhbmd1YWdl IHN1YnRhZ3MgYXJlIHJlc2VydmVkIGZvciBwb3NzaWJsZQogICAgICAgZnV0dXJlIHN0YW5k YXJkaXphdGlvbi4KCiAgIDUuICBBbGwgbGFuZ3VhZ2Ugc3VidGFncyBvZiA1IHRvIDggY2hh cmFjdGVycyBpbiBsZW5ndGggaW4gdGhlIElBTkEKICAgICAgIHJlZ2lzdHJ5IHdlcmUgZGVm aW5lZCB2aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGluIFNlY3Rpb24gMy41CiAgICAg ICBhbmQgTUFZIGJlIHVzZWQgdG8gZm9ybSB0aGUgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcu ICBBdCB0aGUgdGltZQogICAgICAgdGhpcyBkb2N1bWVudCB3YXMgY3JlYXRlZCwgdGhlcmUg d2VyZSBubyBleGFtcGxlcyBvZiB0aGlzIGtpbmQgb2YKICAgICAgIHN1YnRhZyBhbmQgZnV0 dXJlIHJlZ2lzdHJhdGlvbnMgb2YgdGhpcyB0eXBlIHdpbGwgYmUgZGlzY291cmFnZWQ6CiAg ICAgICBwcmltYXJ5IGxhbmd1YWdlcyBhcmUgc3Ryb25nbHkgUkVDT01NRU5ERUQgZm9yIHJl Z2lzdHJhdGlvbiB3aXRoCiAgICAgICBJU08gNjM5LCBhbmQgcHJvcG9zYWxzIHJlamVjdGVk IGJ5IElTTyA2MzkvUkEgd2lsbCBiZSBjbG9zZWx5CiAgICAgICBzY3J1dGluaXplZCBiZWZv cmUgdGhleSBhcmUgcmVnaXN0ZXJlZCB3aXRoIElBTkEuCgoKClBoaWxsaXBzICYgRGF2aXMg ICAgICAgICBFeHBpcmVzIE1hcmNoIDE1LCAyMDA3ICAgICAgICAgICAgICAgICBbUGFnZSA4 XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICBTZXB0ZW1iZXIgMjAwNgoKCiAgIDYuICBUaGUgc2luZ2xlLWNoYXJhY3RlciBz dWJ0YWcgJ3gnIGFzIHRoZSBwcmltYXJ5IHN1YnRhZyBpbmRpY2F0ZXMKICAgICAgIHRoYXQg dGhlIGxhbmd1YWdlIHRhZyBjb25zaXN0cyBzb2xlbHkgb2Ygc3VidGFncyB3aG9zZSBtZWFu aW5nIGlzCiAgICAgICBkZWZpbmVkIGJ5IHByaXZhdGUgYWdyZWVtZW50LiAgRm9yIGV4YW1w bGUsIGluIHRoZSB0YWcgIngtZnItQ0giLAogICAgICAgdGhlIHN1YnRhZ3MgJ2ZyJyBhbmQg J0NIJyBTSE9VTEQgTk9UIGJlIHRha2VuIHRvIHJlcHJlc2VudCB0aGUKICAgICAgIEZyZW5j aCBsYW5ndWFnZSBvciB0aGUgY291bnRyeSBvZiBTd2l0emVybGFuZCAob3IgYW55IG90aGVy IHZhbHVlCiAgICAgICBpbiB0aGUgSUFOQSByZWdpc3RyeSkgdW5sZXNzIHRoZXJlIGlzIGEg cHJpdmF0ZSBhZ3JlZW1lbnQgaW4KICAgICAgIHBsYWNlIHRvIGRvIHNvLiAgU2VlIFNlY3Rp b24gNC41LgoKICAgNy4gIFRoZSBzaW5nbGUtY2hhcmFjdGVyIHN1YnRhZyAnaScgaXMgdXNl ZCBieSBzb21lIGdyYW5kZmF0aGVyZWQKICAgICAgIHRhZ3MgKHNlZSBTZWN0aW9uIDIuMi44 KSBzdWNoIGFzICJpLWtsaW5nb24iIGFuZCAiaS1ibm4iLiAgKE90aGVyCiAgICAgICBncmFu ZGZhdGhlcmVkIHRhZ3MgaGF2ZSBhIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIGluIHRoZWly IGZpcnN0CiAgICAgICBwb3NpdGlvbi4pCgogICA4LiAgT3RoZXIgdmFsdWVzIE1VU1QgTk9U IGJlIGFzc2lnbmVkIHRvIHRoZSBwcmltYXJ5IHN1YnRhZyBleGNlcHQgYnkKICAgICAgIHJl dmlzaW9uIG9yIHVwZGF0ZSBvZiB0aGlzIGRvY3VtZW50LgoKICAgTm90ZTogRm9yIGxhbmd1 YWdlcyB0aGF0IGhhdmUgYm90aCBhbiBJU08gNjM5LTEgdHdvLWNoYXJhY3RlciBjb2RlCiAg IGFuZCBhIHRocmVlIGNoYXJhY3RlciBjb2RlIGFzc2lnbmVkIGJ5IGVpdGhlciBJU08gNjM5 LTIgb3IgSVNPIDY5My0zLAogICBvbmx5IHRoZSBJU08gNjM5LTEgdHdvLWNoYXJhY3RlciBj b2RlIGlzIGRlZmluZWQgaW4gdGhlIElBTkEKICAgcmVnaXN0cnkuCgogICBOb3RlOiBGb3Ig bGFuZ3VhZ2VzIHRoYXQgaGF2ZSBubyBJU08gNjM5LTEgdHdvLWNoYXJhY3RlciBjb2RlIGFu ZCBmb3IKICAgd2hpY2ggdGhlIElTTyA2MzktMi9UIChUZXJtaW5vbG9neSkgY29kZSBhbmQg dGhlIElTTyA2MzktMi9CCiAgIChCaWJsaW9ncmFwaGljKSBjb2RlcyBkaWZmZXIsIG9ubHkg dGhlIFRlcm1pbm9sb2d5IGNvZGUgaXMgZGVmaW5lZCBpbgogICB0aGUgSUFOQSByZWdpc3Ry eS4gIEF0IHRoZSB0aW1lIHRoaXMgZG9jdW1lbnQgd2FzIGNyZWF0ZWQsIGFsbAogICBsYW5n dWFnZXMgdGhhdCBoYWQgYm90aCBraW5kcyBvZiB0aHJlZS1jaGFyYWN0ZXIgY29kZSB3ZXJl IGFsc28KICAgYXNzaWduZWQgYSB0d28tY2hhcmFjdGVyIGNvZGU7IGl0IGlzIG5vdCBleHBl Y3RlZCB0aGF0IGZ1dHVyZQogICBhc3NpZ25tZW50cyBvZiB0aGlzIG5hdHVyZSB3aWxsIG9j Y3VyLgoKICAgTm90ZTogVG8gYXZvaWQgcHJvYmxlbXMgd2l0aCB2ZXJzaW9uaW5nIGFuZCBz dWJ0YWcgY2hvaWNlIGFzCiAgIGV4cGVyaWVuY2VkIGR1cmluZyB0aGUgdHJhbnNpdGlvbiBi ZXR3ZWVuIFJGQyAxNzY2IGFuZCBSRkMgMzA2NiwgYXMKICAgd2VsbCBhcyB0aGUgY2Fub25p Y2FsIG5hdHVyZSBvZiBzdWJ0YWdzIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudCwgdGhlCiAg IElTTyA2MzkgUmVnaXN0cmF0aW9uIEF1dGhvcml0eSBKb2ludCBBZHZpc29yeSBDb21taXR0 ZWUgKElTTyA2MzkvCiAgIFJBLUpBQykgaGFzIGluY2x1ZGVkIHRoZSBmb2xsb3dpbmcgc3Rh dGVtZW50IGluIFtpc282MzkucHJpbl06CgogICAiQSBsYW5ndWFnZSBjb2RlIGFscmVhZHkg aW4gSVNPIDYzOS0yIGF0IHRoZSBwb2ludCBvZiBmcmVlemluZyBJU08KICAgNjM5LTEgc2hh bGwgbm90IGxhdGVyIGJlIGFkZGVkIHRvIElTTyA2MzktMS4gIFRoaXMgaXMgdG8gZW5zdXJl CiAgIGNvbnNpc3RlbmN5IGluIHVzYWdlIG92ZXIgdGltZSwgc2luY2UgdXNlcnMgYXJlIGRp cmVjdGVkIGluIEludGVybmV0CiAgIGFwcGxpY2F0aW9ucyB0byBlbXBsb3kgdGhlIGFscGhh LTMgY29kZSB3aGVuIGFuIGFscGhhLTIgY29kZSBmb3IgdGhhdAogICBsYW5ndWFnZSBpcyBu b3QgYXZhaWxhYmxlLiIKCiAgIEluIG9yZGVyIHRvIGF2b2lkIGluc3RhYmlsaXR5IGluIHRo ZSBjYW5vbmljYWwgZm9ybSBvZiB0YWdzLCBpZiBhCiAgIHR3by1jaGFyYWN0ZXIgY29kZSBp cyBhZGRlZCB0byBJU08gNjM5LTEgZm9yIGEgbGFuZ3VhZ2UgZm9yIHdoaWNoIGEKICAgdGhy ZWUtY2hhcmFjdGVyIGNvZGUgd2FzIGFscmVhZHkgaW5jbHVkZWQgaW4gZWl0aGVyIElTTyA2 MzktMiBvciBJU08KICAgNjM5LTMsIHRoZSB0d28tY2hhcmFjdGVyIGNvZGUgTVVTVCBOT1Qg YmUgcmVnaXN0ZXJlZC4gIFNlZQogICBTZWN0aW9uIDMuNC4KCiAgIEZvciBleGFtcGxlLCBp ZiBzb21lIGNvbnRlbnQgd2VyZSB0YWdnZWQgd2l0aCAnaGF3JyAoSGF3YWlpYW4pLCB3aGlj aAoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAxNSwgMjAwNyAg ICAgICAgICAgICAgICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg bGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDYKCgogICBjdXJy ZW50bHkgaGFzIG5vIHR3by1jaGFyYWN0ZXIgY29kZSwgdGhlIHRhZyB3b3VsZCBub3QgYmUg aW52YWxpZGF0ZWQKICAgaWYgSVNPIDYzOS0xIHdlcmUgdG8gYXNzaWduIGEgdHdvLWNoYXJh Y3RlciBjb2RlIHRvIHRoZSBIYXdhaWlhbgogICBsYW5ndWFnZSBhdCBhIGxhdGVyIGRhdGUu CgogICBGb3IgZXhhbXBsZSwgb25lIG9mIHRoZSBncmFuZGZhdGhlcmVkIElBTkEgcmVnaXN0 cmF0aW9ucyBpcwogICAiaS1lbm9jaGlhbiIuICBUaGUgc3VidGFnICdlbm9jaGlhbicgY291 bGQgYmUgcmVnaXN0ZXJlZCBpbiB0aGUgSUFOQQogICByZWdpc3RyeSBhcyBhIHByaW1hcnkg bGFuZ3VhZ2Ugc3VidGFnIChhc3N1bWluZyB0aGF0IElTTyA2MzkgZG9lcyBub3QKICAgcmVn aXN0ZXIgdGhpcyBsYW5ndWFnZSBmaXJzdCksIG1ha2luZyB0YWdzIHN1Y2ggYXMgImVub2No aWFuLUFRIiBhbmQKICAgImVub2NoaWFuLUxhdG4iIHZhbGlkLgoKMi4yLjIuICBFeHRlbmRl ZCBMYW5ndWFnZSBTdWJ0YWdzCgogICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzIGFyZSB1 c2VkIHRvIGlkZW50aWZ5IGxhbmd1YWdlcyBvciBkaWFsZWN0cwogICB0aGF0IGFyZSBzdWJk aXZpc2lvbnMgd2l0aGluIGFub3RoZXIgbGFuZ3VhZ2UuICBTdWNoIGFuIGVuY2xvc2luZwog ICBsYW5ndWFnZSBpcyBzb21ldGltZXMgY2FsbGVkIGEgImNvbGxlY3RpdmUiIG9yICJtYWNy byIgbGFuZ3VhZ2UuICBUaGUKICAgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHRoZSBleHRl bmRlZCBsYW5ndWFnZSBzdWJ0YWdzOgoKICAgMS4gIFRoZXNlIHN1YnRhZ3Mgd2VyZSBkZWZp bmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFjY29yZGluZyB0bwogICAgICAgYXNzaWdubWVu dHMgZm91bmQgaW4gSVNPIDYzOSBQYXJ0IDMuCgogICAyLiAgQSBzZXF1ZW5jZSBvZiB1cCB0 byB0aHJlZSBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzIE1BWSBhcHBlYXIgaW4KICAgICAg IGEgbGFuZ3VhZ2UgdGFnLiAgVGhpcyBzZXF1ZW5jZSBNVVNUIGZvbGxvdyB0aGUgcHJpbWFy eSBsYW5ndWFnZQogICAgICAgc3VidGFnIGFuZCBwcmVjZWRlIGFueSBvdGhlciBzdWJ0YWdz LgoKICAgMy4gIEVhY2ggZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFnIE1VU1Qgb25seSBiZSB1 c2VkIHdpdGggdGhlIGV4YWN0CiAgICAgICBzZXF1ZW5jZSBvZiBzdWJ0YWdzIHRoYXQgYXBw ZWFycyBpbiB0aGUgJ1ByZWZpeCcgZmllbGQgaW4gaXRzCiAgICAgICByZWdpc3RyeSByZWNv cmQuCgogICA0LiAgVGhlcmUgTUFZIGJlIHVwIHRvIHRocmVlIGV4dGVuZGVkIGxhbmd1YWdl IHN1YnRhZ3MuCgogICA1LiAgT3RoZXIgdmFsdWVzIE1VU1QgTk9UIGJlIGFzc2lnbmVkIHRv IHRoZSBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcKICAgICAgIGV4Y2VwdCBieSByZXZpc2lv biBvciB1cGRhdGUgb2YgdGhpcyBkb2N1bWVudC4KCiAgIEV4dGVuZGVkIGxhbmd1YWdlIHN1 YnRhZyByZWNvcmRzIE1VU1QgaW5jbHVkZSBleGFjdGx5IG9uZSAnUHJlZml4JwogICBmaWVs ZCBpbmRpY2F0aW5nIGFuIGFwcHJvcHJpYXRlIHN1YnRhZyBvciBzZXF1ZW5jZSBvZiBzdWJ0 YWdzIGZvcgogICB0aGF0IGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZy4KCiAgIEZvciBleGFt cGxlLCB0aGUgJ2dhbicgc3VidGFnLCByZXByZXNlbnRpbmcgdGhlICdHYW4nIGRpYWxlY3Qg b2YKICAgQ2hpbmVzZSwgaGFzIGEgcHJlZml4IG9mICJ6aCIgaW4gaXRzIHJlZ2lzdHJ5IHJl Y29yZC4gIFRoZSAnY21uJwogICBzdWJ0YWcsIHJlcHJlc2VudGluZyB0aGUgJ01hbmRhcmlu JyBkaWFsZWN0IG9mIENoaW5lc2UgaGFzIHRoZSBzYW1lCiAgIHByZWZpeC4gIFRodXMsIHRo ZSB0YWdzICJ6aC1nYW4tSGFudCIgb3IgInpoLWNtbi1DTiIgYXJlIGFwcHJvcHJpYXRlLAog ICB3aGlsZSB0aGUgdGFnICJ6aC1jbW4tZ2FuIiBpcyBub3QuCgogICBOb3cgc3VwcG9zZSB0 aGF0ICd4eHgnIGlzIGEgc3VidGFnIHRoYXQgcmVwcmVzZW50cyBhIGRpYWxlY3Qgb2YKICAg J0dhbicuICBJdCB3b3VsZCBoYXZlIGEgJ1ByZWZpeCcgZmllbGQgb2YgInpoLWdhbiIsIG1h a2luZyB0aGUgdGFnCiAgICJ6aC1nYW4teHh4IiBhcHByb3ByaWF0ZSwgd2hpbGUgdGhlIHRh Z3MgInpoLXh4eCIgYW5kICJ6aC14eHgtZ2FuIgogICB3b3VsZCBub3QgYmUgYXBwcm9wcmlh dGUuCgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAxNSwgMjAw NyAgICAgICAgICAgICAgICBbUGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDYKCgoyLjIu My4gIFNjcmlwdCBTdWJ0YWcKCiAgIFNjcmlwdCBzdWJ0YWdzIGFyZSB1c2VkIHRvIGluZGlj YXRlIHRoZSBzY3JpcHQgb3Igd3JpdGluZyBzeXN0ZW0KICAgdmFyaWF0aW9ucyB0aGF0IGRp c3Rpbmd1aXNoIHRoZSB3cml0dGVuIGZvcm1zIG9mIGEgbGFuZ3VhZ2Ugb3IgaXRzCiAgIGRp YWxlY3RzLiAgVGhlIGZvbGxvd2luZyBydWxlcyBhcHBseSB0byB0aGUgc2NyaXB0IHN1YnRh Z3M6CgogICAxLiAgQWxsIGZvdXItY2hhcmFjdGVyIHN1YnRhZ3Mgd2VyZSBkZWZpbmVkIGFj Y29yZGluZyB0bwogICAgICAgW0lTTzE1OTI0XS0tIkNvZGVzIGZvciB0aGUgcmVwcmVzZW50 YXRpb24gb2YgdGhlIG5hbWVzIG9mCiAgICAgICBzY3JpcHRzIjogYWxwaGEtNCBzY3JpcHQg Y29kZXMsIG9yIHN1YnNlcXVlbnRseSBhc3NpZ25lZCBieSB0aGUKICAgICAgIElTTyAxNTky NCBtYWludGVuYW5jZSBhZ2VuY3kgb3IgZ292ZXJuaW5nIHN0YW5kYXJkaXphdGlvbiBib2Rp ZXMsCiAgICAgICBkZW5vdGluZyB0aGUgc2NyaXB0IG9yIHdyaXRpbmcgc3lzdGVtIHVzZWQg aW4gY29uanVuY3Rpb24gd2l0aAogICAgICAgdGhpcyBsYW5ndWFnZS4KCiAgIDIuICBTY3Jp cHQgc3VidGFncyBNVVNUIGltbWVkaWF0ZWx5IGZvbGxvdyB0aGUgcHJpbWFyeSBsYW5ndWFn ZQogICAgICAgc3VidGFnIGFuZCBhbGwgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBhbmQg TVVTVCBvY2N1ciBiZWZvcmUKICAgICAgIGFueSBvdGhlciB0eXBlIG9mIHN1YnRhZyBkZXNj cmliZWQgYmVsb3cuCgogICAzLiAgVGhlIHNjcmlwdCBzdWJ0YWdzICdRYWFhJyB0aHJvdWdo ICdRYWJ4JyBhcmUgcmVzZXJ2ZWQgZm9yIHByaXZhdGUKICAgICAgIHVzZSBpbiBsYW5ndWFn ZSB0YWdzLiAgVGhlc2Ugc3VidGFncyBjb3JyZXNwb25kIHRvIGNvZGVzIHJlc2VydmVkCiAg ICAgICBieSBJU08gMTU5MjQgZm9yIHByaXZhdGUgdXNlLiAgVGhlc2UgY29kZXMgTUFZIGJl IHVzZWQgZm9yIG5vbi0KICAgICAgIHJlZ2lzdGVyZWQgc2NyaXB0IHZhbHVlcy4gIFBsZWFz ZSByZWZlciB0byBTZWN0aW9uIDQuNSBmb3IgbW9yZQogICAgICAgaW5mb3JtYXRpb24gb24g cHJpdmF0ZSB1c2Ugc3VidGFncy4KCiAgIDQuICBTY3JpcHQgc3VidGFncyBNVVNUIE5PVCBi ZSByZWdpc3RlcmVkIHVzaW5nIHRoZSBwcm9jZXNzIGluCiAgICAgICBTZWN0aW9uIDMuNSBv ZiB0aGlzIGRvY3VtZW50LiAgVmFyaWFudCBzdWJ0YWdzIE1BWSBiZSBjb25zaWRlcmVkCiAg ICAgICBmb3IgcmVnaXN0cmF0aW9uIGZvciB0aGF0IHB1cnBvc2UuCgogICA1LiAgVGhlcmUg TVVTVCBiZSBhdCBtb3N0IG9uZSBzY3JpcHQgc3VidGFnIGluIGEgbGFuZ3VhZ2UgdGFnLCBh bmQKICAgICAgIHRoZSBzY3JpcHQgc3VidGFnIFNIT1VMRCBiZSBvbWl0dGVkIHdoZW4gaXQg YWRkcyBubwogICAgICAgZGlzdGluZ3Vpc2hpbmcgdmFsdWUgdG8gdGhlIHRhZyBvciB3aGVu IHRoZSBwcmltYXJ5IGxhbmd1YWdlCiAgICAgICBzdWJ0YWcncyByZWNvcmQgaW5jbHVkZXMg YSBTdXBwcmVzcy1TY3JpcHQgZmllbGQgbGlzdGluZyB0aGUKICAgICAgIGFwcGxpY2FibGUg c2NyaXB0IHN1YnRhZy4KCiAgIEV4YW1wbGU6ICJzci1MYXRuIiByZXByZXNlbnRzIFNlcmJp YW4gd3JpdHRlbiB1c2luZyB0aGUgTGF0aW4gc2NyaXB0LgoKMi4yLjQuICBSZWdpb24gU3Vi dGFnCgogICBSZWdpb24gc3VidGFncyBhcmUgdXNlZCB0byBpbmRpY2F0ZSBsaW5ndWlzdGlj IHZhcmlhdGlvbnMgYXNzb2NpYXRlZAogICB3aXRoIG9yIGFwcHJvcHJpYXRlIHRvIGEgc3Bl Y2lmaWMgY291bnRyeSwgdGVycml0b3J5LCBvciByZWdpb24uCiAgIFR5cGljYWxseSwgYSBy ZWdpb24gc3VidGFnIGlzIHVzZWQgdG8gaW5kaWNhdGUgcmVnaW9uYWwgZGlhbGVjdHMgb3IK ICAgdXNhZ2UsIG9yIHJlZ2lvbi1zcGVjaWZpYyBzcGVsbGluZyBjb252ZW50aW9ucy4gIEEg cmVnaW9uIHN1YnRhZyBjYW4KICAgYWxzbyBiZSB1c2VkIHRvIGluZGljYXRlIHRoYXQgY29u dGVudCBpcyBleHByZXNzZWQgaW4gYSB3YXkgdGhhdCBpcwogICBhcHByb3ByaWF0ZSBmb3Ig dXNlIHRocm91Z2hvdXQgYSByZWdpb24sIGZvciBpbnN0YW5jZSwgU3BhbmlzaAogICBjb250 ZW50IHRhaWxvcmVkIHRvIGJlIHVzZWZ1bCB0aHJvdWdob3V0IExhdGluIEFtZXJpY2EuCgog ICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHRoZSByZWdpb24gc3VidGFnczoKCgoK CgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAxNSwgMjAwNyAgICAg ICAgICAgICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFu Z3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDYKCgogICAxLiAgUmVn aW9uIHN1YnRhZ3MgTVVTVCBmb2xsb3cgYW55IGxhbmd1YWdlLCBleHRlbmRlZCBsYW5ndWFn ZSwgb3IKICAgICAgIHNjcmlwdCBzdWJ0YWdzIGFuZCBNVVNUIHByZWNlZGUgYWxsIG90aGVy IHN1YnRhZ3MuCgogICAyLiAgQWxsIHR3by1jaGFyYWN0ZXIgc3VidGFncyBmb2xsb3dpbmcg dGhlIHByaW1hcnkgc3VidGFnIHdlcmUKICAgICAgIGRlZmluZWQgaW4gdGhlIElBTkEgcmVn aXN0cnkgYWNjb3JkaW5nIHRvIHRoZSBhc3NpZ25tZW50cyBmb3VuZAogICAgICAgaW4gW0lT TzMxNjYtMV0gKCJDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mCiAg ICAgICBjb3VudHJpZXMgYW5kIHRoZWlyIHN1YmRpdmlzaW9ucyAtLSBQYXJ0IDE6IENvdW50 cnkgY29kZXMiKSB1c2luZwogICAgICAgdGhlIGxpc3Qgb2YgYWxwaGEtMiBjb3VudHJ5IGNv ZGVzLCBvciB1c2luZyBhc3NpZ25tZW50cwogICAgICAgc3Vic2VxdWVudGx5IG1hZGUgYnkg dGhlIElTTyAzMTY2IG1haW50ZW5hbmNlIGFnZW5jeSBvciBnb3Zlcm5pbmcKICAgICAgIHN0 YW5kYXJkaXphdGlvbiBib2RpZXMuCgogICAzLiAgQWxsIHRocmVlLWNoYXJhY3RlciBzdWJ0 YWdzIGNvbnNpc3Rpbmcgb2YgZGlnaXQgKG51bWVyaWMpCiAgICAgICBjaGFyYWN0ZXJzIGZv bGxvd2luZyB0aGUgcHJpbWFyeSBzdWJ0YWcgd2VyZSBkZWZpbmVkIGluIHRoZSBJQU5BCiAg ICAgICByZWdpc3RyeSBhY2NvcmRpbmcgdG8gdGhlIGFzc2lnbm1lbnRzIGZvdW5kIGluIFVO IFN0YW5kYXJkCiAgICAgICBDb3VudHJ5IG9yIEFyZWEgQ29kZXMgZm9yIFN0YXRpc3RpY2Fs IFVzZSBbVU5fTS40OV0gb3IKICAgICAgIGFzc2lnbm1lbnRzIHN1YnNlcXVlbnRseSBtYWRl IGJ5IHRoZSBnb3Zlcm5pbmcgc3RhbmRhcmRzIGJvZHkuCiAgICAgICBOb3RlIHRoYXQgbm90 IGFsbCBvZiB0aGUgVU4gTS40OSBjb2RlcyBhcmUgZGVmaW5lZCBpbiB0aGUgSUFOQQogICAg ICAgcmVnaXN0cnkuICBUaGUgZm9sbG93aW5nIHJ1bGVzIGRlZmluZSB3aGljaCBjb2RlcyBh cmUgZW50ZXJlZAogICAgICAgaW50byB0aGUgcmVnaXN0cnkgYXMgdmFsaWQgc3VidGFnczoK CiAgICAgICBBLiAgVU4gbnVtZXJpYyBjb2RlcyBhc3NpZ25lZCB0byAnbWFjcm8tZ2VvZ3Jh cGhpY2FsCiAgICAgICAgICAgKGNvbnRpbmVudGFsKScgb3Igc3ViLXJlZ2lvbnMgTVVTVCBi ZSByZWdpc3RlcmVkIGluIHRoZQogICAgICAgICAgIHJlZ2lzdHJ5LiAgVGhlc2UgY29kZXMg YXJlIG5vdCBhc3NvY2lhdGVkIHdpdGggYW4gYXNzaWduZWQKICAgICAgICAgICBJU08gMzE2 NiBhbHBoYS0yIGNvZGUgYW5kIHJlcHJlc2VudCBzdXByYS1uYXRpb25hbCBhcmVhcywKICAg ICAgICAgICB1c3VhbGx5IGNvdmVyaW5nIG1vcmUgdGhhbiBvbmUgbmF0aW9uLCBzdGF0ZSwg cHJvdmluY2UsIG9yCiAgICAgICAgICAgdGVycml0b3J5LgoKICAgICAgIEIuICBVTiBudW1l cmljIGNvZGVzIGZvciAnZWNvbm9taWMgZ3JvdXBpbmdzJyBvciAnb3RoZXIKICAgICAgICAg ICBncm91cGluZ3MnIE1VU1QgTk9UIGJlIHJlZ2lzdGVyZWQgaW4gdGhlIElBTkEgcmVnaXN0 cnkgYW5kCiAgICAgICAgICAgTVVTVCBOT1QgYmUgdXNlZCB0byBmb3JtIGxhbmd1YWdlIHRh Z3MuCgogICAgICAgQy4gIFVOIG51bWVyaWMgY29kZXMgZm9yIGNvdW50cmllcyBvciBhcmVh cyB3aXRoIGFtYmlndW91cyBJU08KICAgICAgICAgICAzMTY2IGFscGhhLTIgY29kZXMsIHdo ZW4gZW50ZXJlZCBpbnRvIHRoZSByZWdpc3RyeSwgTVVTVCBiZQogICAgICAgICAgIGRlZmlu ZWQgYWNjb3JkaW5nIHRvIHRoZSBydWxlcyBpbiBTZWN0aW9uIDMuNCBhbmQgTVVTVCBiZQog ICAgICAgICAgIHVzZWQgdG8gZm9ybSBsYW5ndWFnZSB0YWdzIHRoYXQgcmVwcmVzZW50IHRo ZSBjb3VudHJ5IG9yCiAgICAgICAgICAgcmVnaW9uIGZvciB3aGljaCB0aGV5IGFyZSBkZWZp bmVkLgoKICAgICAgIEQuICBVTiBudW1lcmljIGNvZGVzIGZvciBjb3VudHJpZXMgb3IgYXJl YXMgZm9yIHdoaWNoIHRoZXJlIGlzIGFuCiAgICAgICAgICAgYXNzb2NpYXRlZCBJU08gMzE2 NiBhbHBoYS0yIGNvZGUgaW4gdGhlIHJlZ2lzdHJ5IE1VU1QgTk9UIGJlCiAgICAgICAgICAg ZW50ZXJlZCBpbnRvIHRoZSByZWdpc3RyeSBhbmQgTVVTVCBOT1QgYmUgdXNlZCB0byBmb3Jt CiAgICAgICAgICAgbGFuZ3VhZ2UgdGFncy4gIE5vdGUgdGhhdCB0aGUgSVNPIDMxNjYtYmFz ZWQgc3VidGFnIGluIHRoZQogICAgICAgICAgIHJlZ2lzdHJ5IE1VU1QgYWN0dWFsbHkgYmUg YXNzb2NpYXRlZCB3aXRoIHRoZSBVTiBNLjQ5IGNvZGUgaW4KICAgICAgICAgICBxdWVzdGlv bi4KCiAgICAgICBFLiAgVU4gbnVtZXJpYyBjb2RlcyBhbmQgSVNPIDMxNjYgYWxwaGEtMiBj b2RlcyBmb3IgY291bnRyaWVzIG9yCiAgICAgICAgICAgYXJlYXMgbGlzdGVkIGFzIGVsaWdp YmxlIGZvciByZWdpc3RyYXRpb24gaW4gW2luaXRpYWwtCiAgICAgICAgICAgcmVnaXN0cnld IGJ1dCBub3QgcHJlc2VudGx5IHJlZ2lzdGVyZWQgTUFZIGJlIGVudGVyZWQgaW50bwogICAg ICAgICAgIHRoZSBJQU5BIHJlZ2lzdHJ5IHZpYSB0aGUgcHJvY2VzcyBkZXNjcmliZWQgaW4g U2VjdGlvbiAzLjUuCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNo IDE1LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDEyXQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAw NgoKCiAgICAgICAgICAgT25jZSByZWdpc3RlcmVkLCB0aGVzZSBjb2RlcyBNQVkgYmUgdXNl ZCB0byBmb3JtIGxhbmd1YWdlCiAgICAgICAgICAgdGFncy4KCiAgICAgICBGLiAgQWxsIG90 aGVyIFVOIG51bWVyaWMgY29kZXMgZm9yIGNvdW50cmllcyBvciBhcmVhcyB0aGF0IGRvIG5v dAogICAgICAgICAgIGhhdmUgYW4gYXNzb2NpYXRlZCBJU08gMzE2NiBhbHBoYS0yIGNvZGUg TVVTVCBOT1QgYmUgZW50ZXJlZAogICAgICAgICAgIGludG8gdGhlIHJlZ2lzdHJ5IGFuZCBN VVNUIE5PVCBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncy4KICAgICAgICAgICBGb3Ig bW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGVzZSBjb2Rlcywgc2VlIFNlY3Rpb24gMy40LgoK ICAgNC4gIE5vdGU6IFRoZSBhbHBoYW51bWVyaWMgY29kZXMgaW4gQXBwZW5kaXggWCBvZiB0 aGUgVU4gZG9jdW1lbnQKICAgICAgIE1VU1QgTk9UIGJlIGVudGVyZWQgaW50byB0aGUgcmVn aXN0cnkgYW5kIE1VU1QgTk9UIGJlIHVzZWQgdG8KICAgICAgIGZvcm0gbGFuZ3VhZ2UgdGFn cy4gIChBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50IHdhcyBjcmVhdGVkLAogICAgICAgdGhl c2UgdmFsdWVzIG1hdGNoZWQgdGhlIElTTyAzMTY2IGFscGhhLTIgY29kZXMuKQoKICAgNS4g IFRoZXJlIE1VU1QgYmUgYXQgbW9zdCBvbmUgcmVnaW9uIHN1YnRhZyBpbiBhIGxhbmd1YWdl IHRhZyBhbmQgdGhlCiAgICAgICByZWdpb24gc3VidGFnIE1BWSBiZSBvbWl0dGVkLCBhcyB3 aGVuIGl0IGFkZHMgbm8gZGlzdGluZ3Vpc2hpbmcKICAgICAgIHZhbHVlIHRvIHRoZSB0YWcu CgogICA2LiAgVGhlIHJlZ2lvbiBzdWJ0YWdzICdBQScsICdRTSctJ1FaJywgJ1hBJy0nWFon LCBhbmQgJ1paJyBhcmUKICAgICAgIHJlc2VydmVkIGZvciBwcml2YXRlIHVzZSBpbiBsYW5n dWFnZSB0YWdzLiAgVGhlc2Ugc3VidGFncwogICAgICAgY29ycmVzcG9uZCB0byBjb2RlcyBy ZXNlcnZlZCBieSBJU08gMzE2NiBmb3IgcHJpdmF0ZSB1c2UuICBUaGVzZQogICAgICAgY29k ZXMgTUFZIGJlIHVzZWQgZm9yIHByaXZhdGUgdXNlIHJlZ2lvbiBzdWJ0YWdzIChpbnN0ZWFk IG9mCiAgICAgICB1c2luZyBhIHByaXZhdGUgdXNlIHN1YnRhZyBzZXF1ZW5jZSkuICBQbGVh c2UgcmVmZXIgdG8KICAgICAgIFNlY3Rpb24gNC41IGZvciBtb3JlIGluZm9ybWF0aW9uIG9u IHByaXZhdGUgdXNlIHN1YnRhZ3MuCgogICAiZGUtQ0giIHJlcHJlc2VudHMgR2VybWFuICgn ZGUnKSBhcyB1c2VkIGluIFN3aXR6ZXJsYW5kICgnQ0gnKS4KCiAgICJzci1MYXRuLUNTIiBy ZXByZXNlbnRzIFNlcmJpYW4gKCdzcicpIHdyaXR0ZW4gdXNpbmcgTGF0aW4gc2NyaXB0CiAg ICgnTGF0bicpIGFzIHVzZWQgaW4gU2VyYmlhIGFuZCBNb250ZW5lZ3JvICgnQ1MnKS4KCiAg ICJlcy00MTkiIHJlcHJlc2VudHMgU3BhbmlzaCAoJ2VzJykgYXBwcm9wcmlhdGUgdG8gdGhl IFVOLWRlZmluZWQKICAgTGF0aW4gQW1lcmljYSBhbmQgQ2FyaWJiZWFuIHJlZ2lvbiAoJzQx OScpLgoKMi4yLjUuICBWYXJpYW50IFN1YnRhZ3MKCiAgIFZhcmlhbnQgc3VidGFncyBhcmUg dXNlZCB0byBpbmRpY2F0ZSBhZGRpdGlvbmFsLCB3ZWxsLXJlY29nbml6ZWQKICAgdmFyaWF0 aW9ucyB0aGF0IGRlZmluZSBhIGxhbmd1YWdlIG9yIGl0cyBkaWFsZWN0cyB0aGF0IGFyZSBu b3QKICAgY292ZXJlZCBieSBvdGhlciBhdmFpbGFibGUgc3VidGFncy4gIFRoZSBmb2xsb3dp bmcgcnVsZXMgYXBwbHkgdG8gdGhlCiAgIHZhcmlhbnQgc3VidGFnczoKCiAgIDEuICBWYXJp YW50IHN1YnRhZ3MgYXJlIG5vdCBhc3NvY2lhdGVkIHdpdGggYW55IGV4dGVybmFsIHN0YW5k YXJkLgogICAgICAgVmFyaWFudCBzdWJ0YWdzIGFuZCB0aGVpciBtZWFuaW5ncyBhcmUgZGVm aW5lZCBieSB0aGUKICAgICAgIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGRlZmluZWQgaW4gU2Vj dGlvbiAzLjUuCgogICAyLiAgVmFyaWFudCBzdWJ0YWdzIE1VU1QgZm9sbG93IGFsbCBvZiB0 aGUgb3RoZXIgZGVmaW5lZCBzdWJ0YWdzLCBidXQKICAgICAgIHByZWNlZGUgYW55IGV4dGVu c2lvbiBvciBwcml2YXRlIHVzZSBzdWJ0YWcgc2VxdWVuY2VzLgoKICAgMy4gIE1vcmUgdGhh biBvbmUgdmFyaWFudCBNQVkgYmUgdXNlZCB0byBmb3JtIHRoZSBsYW5ndWFnZSB0YWcuCgoK CgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAxNSwgMjAwNyAgICAg ICAgICAgICAgICBbUGFnZSAxM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFu Z3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDYKCgogICA0LiAgVmFy aWFudCBzdWJ0YWdzIE1VU1QgYmUgcmVnaXN0ZXJlZCB3aXRoIElBTkEgYWNjb3JkaW5nIHRv IHRoZQogICAgICAgcnVsZXMgaW4gU2VjdGlvbiAzLjUgb2YgdGhpcyBkb2N1bWVudCBiZWZv cmUgYmVpbmcgdXNlZCB0byBmb3JtCiAgICAgICBsYW5ndWFnZSB0YWdzLiAgSW4gb3JkZXIg dG8gZGlzdGluZ3Vpc2ggdmFyaWFudHMgZnJvbSBvdGhlciB0eXBlcwogICAgICAgb2Ygc3Vi dGFncywgcmVnaXN0cmF0aW9ucyBNVVNUIG1lZXQgdGhlIGZvbGxvd2luZyBsZW5ndGggYW5k CiAgICAgICBjb250ZW50IHJlc3RyaWN0aW9uczoKCiAgICAgICAxLiAgVmFyaWFudCBzdWJ0 YWdzIHRoYXQgYmVnaW4gd2l0aCBhIGxldHRlciAoYS16LCBBLVopIE1VU1QgYmUKICAgICAg ICAgICBhdCBsZWFzdCBmaXZlIGNoYXJhY3RlcnMgbG9uZy4KCiAgICAgICAyLiAgVmFyaWFu dCBzdWJ0YWdzIHRoYXQgYmVnaW4gd2l0aCBhIGRpZ2l0ICgwLTkpIE1VU1QgYmUgYXQKICAg ICAgICAgICBsZWFzdCBmb3VyIGNoYXJhY3RlcnMgbG9uZy4KCiAgIFZhcmlhbnQgc3VidGFn IHJlY29yZHMgaW4gdGhlIGxhbmd1YWdlIHN1YnRhZyByZWdpc3RyeSBNQVkgaW5jbHVkZQog ICBvbmUgb3IgbW9yZSAnUHJlZml4JyBmaWVsZHMsIHdoaWNoIGluZGljYXRlIHRoZSBsYW5n dWFnZSB0YWcgb3IgdGFncwogICB0aGF0IHdvdWxkIG1ha2UgYSBzdWl0YWJsZSBwcmVmaXgg KHdpdGggb3RoZXIgc3VidGFncywgYXMKICAgYXBwcm9wcmlhdGUpIGluIGZvcm1pbmcgYSBs YW5ndWFnZSB0YWcgd2l0aCB0aGUgdmFyaWFudC4gIEZvcgogICBleGFtcGxlLCB0aGUgc3Vi dGFnICduZWRpcycgaGFzIGEgUHJlZml4IG9mICJzbCIsIG1ha2luZyBpdCBzdWl0YWJsZQog ICB0byBmb3JtIGxhbmd1YWdlIHRhZ3Mgc3VjaCBhcyAic2wtbmVkaXMiIGFuZCAic2wtSVQt bmVkaXMiLCBidXQgbm90CiAgIHN1aXRhYmxlIGZvciB1c2UgaW4gYSB0YWcgc3VjaCBhcyAi emgtbmVkaXMiIG9yICJpdC1JVC1uZWRpcyIuCgogICAic2wtbmVkaXMiIHJlcHJlc2VudHMg dGhlIE5hdGlzb25lIG9yIE5hZGl6YSBkaWFsZWN0IG9mIFNsb3Zlbmlhbi4KCiAgICJkZS1D SC0xOTk2IiByZXByZXNlbnRzIEdlcm1hbiBhcyB1c2VkIGluIFN3aXR6ZXJsYW5kIGFuZCBh cyB3cml0dGVuCiAgIHVzaW5nIHRoZSBzcGVsbGluZyByZWZvcm0gYmVnaW5uaW5nIGluIHRo ZSB5ZWFyIDE5OTYgQy5FLgoKICAgTW9zdCB2YXJpYW50cyB0aGF0IHNoYXJlIGEgcHJlZml4 IGFyZSBtdXR1YWxseSBleGNsdXNpdmUuICBGb3IKICAgZXhhbXBsZSwgdGhlIEdlcm1hbiBv cnRob2dyYXBoaWMgdmFyaWF0aW9ucyAnMTk5NicgYW5kICcxOTAxJyBTSE9VTEQKICAgTk9U IGJlIHVzZWQgaW4gdGhlIHNhbWUgdGFnLCBhcyB0aGV5IHJlcHJlc2VudCB0aGUgZGF0ZXMg b2YgZGlmZmVyZW50CiAgIHNwZWxsaW5nIHJlZm9ybXMuICBBIHZhcmlhbnQgdGhhdCBjYW4g bWVhbmluZ2Z1bGx5IGJlIHVzZWQgaW4KICAgY29tYmluYXRpb24gd2l0aCBhbm90aGVyIHZh cmlhbnQgU0hPVUxEIGluY2x1ZGUgYSAnUHJlZml4JyBmaWVsZCBpbgogICBpdHMgcmVnaXN0 cnkgcmVjb3JkIHRoYXQgbGlzdHMgdGhhdCBvdGhlciB2YXJpYW50LiAgRm9yIGV4YW1wbGUs IGlmCiAgIGFub3RoZXIgR2VybWFuIHZhcmlhbnQgJ2V4YW1wbGUnIHdlcmUgY3JlYXRlZCB0 aGF0IG1hZGUgc2Vuc2UgdG8gdXNlCiAgIHdpdGggJzE5OTYnLCB0aGVuICdleGFtcGxlJyBz aG91bGQgaW5jbHVkZSB0d28gUHJlZml4IGZpZWxkczogImRlIgogICBhbmQgImRlLTE5OTYi LgoKMi4yLjYuICBFeHRlbnNpb24gU3VidGFncwoKICAgRXh0ZW5zaW9ucyBwcm92aWRlIGEg bWVjaGFuaXNtIGZvciBleHRlbmRpbmcgbGFuZ3VhZ2UgdGFncyBmb3IgdXNlIGluCiAgIHZh cmlvdXMgYXBwbGljYXRpb25zLiAgU2VlIFNlY3Rpb24gMy43LiAgVGhlIGZvbGxvd2luZyBy dWxlcyBhcHBseSB0bwogICBleHRlbnNpb25zOgoKICAgMS4gICBFeHRlbnNpb24gc3VidGFn cyBhcmUgc2VwYXJhdGVkIGZyb20gdGhlIG90aGVyIHN1YnRhZ3MgZGVmaW5lZAogICAgICAg IGluIHRoaXMgZG9jdW1lbnQgYnkgYSBzaW5nbGUtY2hhcmFjdGVyIHN1YnRhZyAoInNpbmds ZXRvbiIpLgogICAgICAgIFRoZSBzaW5nbGV0b24gTVVTVCBiZSBvbmUgYWxsb2NhdGVkIHRv IGEgcmVnaXN0cmF0aW9uIGF1dGhvcml0eQogICAgICAgIHZpYSB0aGUgbWVjaGFuaXNtIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDMuNyBhbmQgTVVTVCBOT1QgYmUgdGhlCiAgICAgICAgbGV0 dGVyICd4Jywgd2hpY2ggaXMgcmVzZXJ2ZWQgZm9yIHByaXZhdGUgdXNlIHN1YnRhZyBzZXF1 ZW5jZXMuCgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMTUs IDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMTRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA2CgoK ICAgMi4gICBOb3RlOiBQcml2YXRlIHVzZSBzdWJ0YWcgc2VxdWVuY2VzIHN0YXJ0aW5nIHdp dGggdGhlIHNpbmdsZXRvbgogICAgICAgIHN1YnRhZyAneCcgYXJlIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDIuMi43IGJlbG93LgoKICAgMy4gICBBbiBleHRlbnNpb24gTVVTVCBmb2xsb3cg YXQgbGVhc3QgYSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZy4KICAgICAgICBUaGF0IGlzLCBh IGxhbmd1YWdlIHRhZyBjYW5ub3QgYmVnaW4gd2l0aCBhbiBleHRlbnNpb24uCiAgICAgICAg RXh0ZW5zaW9ucyBleHRlbmQgbGFuZ3VhZ2UgdGFncywgdGhleSBkbyBub3Qgb3ZlcnJpZGUg b3IgcmVwbGFjZQogICAgICAgIHRoZW0uICBGb3IgZXhhbXBsZSwgImEtdmFsdWUiIGlzIG5v dCBhIHdlbGwtZm9ybWVkIGxhbmd1YWdlIHRhZywKICAgICAgICB3aGlsZSAiZGUtYS12YWx1 ZSIgaXMuCgogICA0LiAgIEVhY2ggc2luZ2xldG9uIHN1YnRhZyBNVVNUIGFwcGVhciBhdCBt b3N0IG9uZSB0aW1lIGluIGVhY2ggdGFnCiAgICAgICAgKG90aGVyIHRoYW4gYXMgYSBwcml2 YXRlIHVzZSBzdWJ0YWcpLiAgVGhhdCBpcywgc2luZ2xldG9uCiAgICAgICAgc3VidGFncyBN VVNUIE5PVCBiZSByZXBlYXRlZC4gIEZvciBleGFtcGxlLCB0aGUgdGFnICJlbi1hLWJiYi1h LQogICAgICAgIGNjYyIgaXMgaW52YWxpZCBiZWNhdXNlIHRoZSBzdWJ0YWcgJ2EnIGFwcGVh cnMgdHdpY2UuICBOb3RlIHRoYXQKICAgICAgICB0aGUgdGFnICJlbi1hLWJiYi14LWEtY2Nj IiBpcyB2YWxpZCBiZWNhdXNlIHRoZSBzZWNvbmQKICAgICAgICBhcHBlYXJhbmNlIG9mIHRo ZSBzaW5nbGV0b24gJ2EnIGlzIGluIGEgcHJpdmF0ZSB1c2Ugc2VxdWVuY2UuCgogICA1LiAg IEV4dGVuc2lvbiBzdWJ0YWdzIE1VU1QgbWVldCBhbGwgb2YgdGhlIHJlcXVpcmVtZW50cyBm b3IgdGhlCiAgICAgICAgY29udGVudCBhbmQgZm9ybWF0IG9mIHN1YnRhZ3MgZGVmaW5lZCBp biB0aGlzIGRvY3VtZW50LgoKICAgNi4gICBFeHRlbnNpb24gc3VidGFncyBNVVNUIG1lZXQg d2hhdGV2ZXIgcmVxdWlyZW1lbnRzIGFyZSBzZXQgYnkgdGhlCiAgICAgICAgZG9jdW1lbnQg dGhhdCBkZWZpbmVzIHRoZWlyIHNpbmdsZXRvbiBwcmVmaXggYW5kIHdoYXRldmVyCiAgICAg ICAgcmVxdWlyZW1lbnRzIGFyZSBwcm92aWRlZCBieSB0aGUgbWFpbnRhaW5pbmcgYXV0aG9y aXR5LgoKICAgNy4gICBFYWNoIGV4dGVuc2lvbiBzdWJ0YWcgTVVTVCBiZSBmcm9tIHR3byB0 byBlaWdodCBjaGFyYWN0ZXJzIGxvbmcKICAgICAgICBhbmQgY29uc2lzdCBzb2xlbHkgb2Yg bGV0dGVycyBvciBkaWdpdHMsIHdpdGggZWFjaCBzdWJ0YWcKICAgICAgICBzZXBhcmF0ZWQg YnkgYSBzaW5nbGUgJy0nLgoKICAgOC4gICBFYWNoIHNpbmdsZXRvbiBNVVNUIGJlIGZvbGxv d2VkIGJ5IGF0IGxlYXN0IG9uZSBleHRlbnNpb24KICAgICAgICBzdWJ0YWcuICBGb3IgZXhh bXBsZSwgdGhlIHRhZyAidGxoLWEtYi1mb28iIGlzIGludmFsaWQgYmVjYXVzZQogICAgICAg IHRoZSBmaXJzdCBzaW5nbGV0b24gJ2EnIGlzIGZvbGxvd2VkIGltbWVkaWF0ZWx5IGJ5IGFu b3RoZXIKICAgICAgICBzaW5nbGV0b24gJ2InLgoKICAgOS4gICBFeHRlbnNpb24gc3VidGFn cyBNVVNUIGZvbGxvdyBhbGwgbGFuZ3VhZ2UsIGV4dGVuZGVkIGxhbmd1YWdlLAogICAgICAg IHNjcmlwdCwgcmVnaW9uLCBhbmQgdmFyaWFudCBzdWJ0YWdzIGluIGEgdGFnLgoKICAgMTAu ICBBbGwgc3VidGFncyBmb2xsb3dpbmcgdGhlIHNpbmdsZXRvbiBhbmQgYmVmb3JlIGFub3Ro ZXIgc2luZ2xldG9uCiAgICAgICAgYXJlIHBhcnQgb2YgdGhlIGV4dGVuc2lvbi4gIEV4YW1w bGU6IEluIHRoZSB0YWcgImZyLWEtTGF0biIsIHRoZQogICAgICAgIHN1YnRhZyAnTGF0bicg ZG9lcyBub3QgcmVwcmVzZW50IHRoZSBzY3JpcHQgc3VidGFnICdMYXRuJwogICAgICAgIGRl ZmluZWQgaW4gdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5LiAgSXRzIG1lYW5p bmcgaXMKICAgICAgICBkZWZpbmVkIGJ5IHRoZSBleHRlbnNpb24gJ2EnLgoKICAgMTEuICBJ biB0aGUgZXZlbnQgdGhhdCBtb3JlIHRoYW4gb25lIGV4dGVuc2lvbiBhcHBlYXJzIGluIGEg c2luZ2xlCiAgICAgICAgdGFnLCB0aGUgdGFnIFNIT1VMRCBiZSBjYW5vbmljYWxpemVkIGFz IGRlc2NyaWJlZCBpbgogICAgICAgIFNlY3Rpb24gNC40LgoKICAgRm9yIGV4YW1wbGUsIGlm IHRoZSBwcmVmaXggc2luZ2xldG9uICdyJyBhbmQgdGhlIHNob3duIHN1YnRhZ3Mgd2VyZQog ICBkZWZpbmVkLCB0aGVuIHRoZSBmb2xsb3dpbmcgdGFnIHdvdWxkIGJlIGEgdmFsaWQgZXhh bXBsZTogImVuLUxhdG4tCiAgIEdCLWJvb250LXItZXh0ZW5kZWQtc2VxdWVuY2UteC1wcml2 YXRlIgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAxNSwgMjAw NyAgICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDYKCgoyLjIu Ny4gIFByaXZhdGUgVXNlIFN1YnRhZ3MKCiAgIFByaXZhdGUgdXNlIHN1YnRhZ3MgYXJlIHVz ZWQgdG8gaW5kaWNhdGUgZGlzdGluY3Rpb25zIGluIGxhbmd1YWdlCiAgIGltcG9ydGFudCBp biBhIGdpdmVuIGNvbnRleHQgYnkgcHJpdmF0ZSBhZ3JlZW1lbnQuICBUaGUgZm9sbG93aW5n CiAgIHJ1bGVzIGFwcGx5IHRvIHByaXZhdGUgdXNlIHN1YnRhZ3M6CgogICAxLiAgUHJpdmF0 ZSB1c2Ugc3VidGFncyBhcmUgc2VwYXJhdGVkIGZyb20gdGhlIG90aGVyIHN1YnRhZ3MgZGVm aW5lZAogICAgICAgaW4gdGhpcyBkb2N1bWVudCBieSB0aGUgcmVzZXJ2ZWQgc2luZ2xlLWNo YXJhY3RlciBzdWJ0YWcgJ3gnLgoKICAgMi4gIFByaXZhdGUgdXNlIHN1YnRhZ3MgTVVTVCBj b25mb3JtIHRvIHRoZSBmb3JtYXQgYW5kIGNvbnRlbnQKICAgICAgIGNvbnN0cmFpbnRzIGRl ZmluZWQgaW4gdGhlIEFCTkYgZm9yIGFsbCBzdWJ0YWdzLgoKICAgMy4gIFByaXZhdGUgdXNl IHN1YnRhZ3MgTVVTVCBmb2xsb3cgYWxsIGxhbmd1YWdlLCBleHRlbmRlZCBsYW5ndWFnZSwK ICAgICAgIHNjcmlwdCwgcmVnaW9uLCB2YXJpYW50LCBhbmQgZXh0ZW5zaW9uIHN1YnRhZ3Mg aW4gdGhlIHRhZy4KICAgICAgIEFub3RoZXIgd2F5IG9mIHNheWluZyB0aGlzIGlzIHRoYXQg YWxsIHN1YnRhZ3MgZm9sbG93aW5nIHRoZQogICAgICAgc2luZ2xldG9uICd4JyBNVVNUIGJl IGNvbnNpZGVyZWQgcHJpdmF0ZSB1c2UuICBFeGFtcGxlOiBUaGUKICAgICAgIHN1YnRhZyAn VVMnIGluIHRoZSB0YWcgImVuLXgtVVMiIGlzIGEgcHJpdmF0ZSB1c2Ugc3VidGFnLgoKICAg NC4gIEEgdGFnIE1BWSBjb25zaXN0IGVudGlyZWx5IG9mIHByaXZhdGUgdXNlIHN1YnRhZ3Mu CgogICA1LiAgTm8gc291cmNlIGlzIGRlZmluZWQgZm9yIHByaXZhdGUgdXNlIHN1YnRhZ3Mu ICBVc2Ugb2YgcHJpdmF0ZSB1c2UKICAgICAgIHN1YnRhZ3MgaXMgYnkgcHJpdmF0ZSBhZ3Jl ZW1lbnQgb25seS4KCiAgIDYuICBQcml2YXRlIHVzZSBzdWJ0YWdzIGFyZSBOT1QgUkVDT01N RU5ERUQgd2hlcmUgYWx0ZXJuYXRpdmVzIGV4aXN0CiAgICAgICBvciBmb3IgZ2VuZXJhbCBp bnRlcmNoYW5nZS4gIFNlZSBTZWN0aW9uIDQuNSBmb3IgbW9yZSBpbmZvcm1hdGlvbgogICAg ICAgb24gcHJpdmF0ZSB1c2Ugc3VidGFnIGNob2ljZS4KCiAgIEZvciBleGFtcGxlOiBVc2Vy cyB3aG8gd2lzaGVkIHRvIHV0aWxpemUgY29kZXMgZnJvbSB0aGUgRXRobm9sb2d1ZQogICBw dWJsaWNhdGlvbiBvZiBTSUwgSW50ZXJuYXRpb25hbCBmb3IgbGFuZ3VhZ2UgaWRlbnRpZmlj YXRpb24gbWlnaHQKICAgYWdyZWUgdG8gZXhjaGFuZ2UgdGFncyBzdWNoIGFzICJhei1BcmFi LXgtQVpFLWRlcmJlbmQiLiAgVGhpcyBleGFtcGxlCiAgIGNvbnRhaW5zIHR3byBwcml2YXRl IHVzZSBzdWJ0YWdzLiAgVGhlIGZpcnN0IGlzICdBWkUnIGFuZCB0aGUgc2Vjb25kCiAgIGlz ICdkZXJiZW5kJy4KCjIuMi44LiAgR3JhbmRmYXRoZXJlZCBSZWdpc3RyYXRpb25zCgogICBQ cmlvciB0byBSRkMgNDY0Niwgd2hvbGUgbGFuZ3VhZ2UgdGFncyB3ZXJlIHJlZ2lzdGVyZWQg YWNjb3JkaW5nIHRvCiAgIHRoZSBydWxlcyBpbiBSRkMgMTc2NiBhbmQvb3IgUkZDIDMwNjYu ICBUaGVzZSByZWdpc3RlcmVkIHRhZ3MKICAgbWFpbnRhaW4gdGhlaXIgdmFsaWRpdHkuICBU aG9zZSB0YWdzIHdoaWNoIHdlcmUgbWFkZSBvYnNvbGV0ZSBvcgogICByZWR1bmRhbnQgYnkg dGhlIGFkdmVudCBvZiBSRkMgNDY0NiBvciBieSBzdWJzZXF1ZW50IHJlZ2lzdHJhdGlvbiBv ZgogICBzdWJ0YWdzIGFyZSBtYWludGFpbmVkIGluIHRoZSByZWdpc3RyeSBpbiByZWNvcmRz IGFzICJyZWR1bmRhbnQiIHRhZwogICByZWNvcmRzLiAgVGhvc2UgdGhhdCB3b3VsZCBub3Qg YmUgd2VsbC1mb3JtZWQgYWNjb3JkaW5nIHRvIHRoZSBBQk5GCiAgIGluIHRoaXMgZG9jdW1l bnQgb3IgdGhhdCBjb250YWluIHN1YnRhZ3MgdGhhdCBkbyBub3QgaW5kaXZpZHVhbGx5CiAg IGFwcGVhciBpbiB0aGUgcmVnaXN0cnkgYXJlIG1haW50YWluZWQgaW4gdGhlIHJlZ2lzdHJ5 IGluIHJlY29yZCBvZgogICB0aGUgImdyYW5kZmF0aGVyZWQiIHR5cGUuICBHcmFuZGZhdGhl cmVkIHRhZ3MgY29udGFpbiBvbmUgb3IgbW9yZQogICBzdWJ0YWdzIHRoYXQgYXJlIG5vdCBk ZWZpbmVkIGluIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgKHNlZQogICBTZWN0aW9u IDMpLiAgUmVkdW5kYW50IHRhZ3MgY29uc2lzdCBlbnRpcmVseSBvZiBzdWJ0YWdzIGRlZmlu ZWQgYWJvdmUKICAgYW5kIHdob3NlIGluZGVwZW5kZW50IHJlZ2lzdHJhdGlvbiBpcyBzdXBl cnNlZGVkIGJ5IHRoaXMgZG9jdW1lbnQuCiAgIEZvciBtb3JlIGluZm9ybWF0aW9uIHNlZSBT ZWN0aW9uIDMuOC4KCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2gg MTUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMTZdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA2 CgoKMi4yLjkuICBDbGFzc2VzIG9mIENvbmZvcm1hbmNlCgogICBJbXBsZW1lbnRhdGlvbnMg c29tZXRpbWVzIG5lZWQgdG8gZGVzY3JpYmUgdGhlaXIgY2FwYWJpbGl0aWVzIHdpdGgKICAg cmVnYXJkIHRvIHRoZSBydWxlcyBhbmQgcHJhY3RpY2VzIGRlc2NyaWJlZCBpbiB0aGlzIGRv Y3VtZW50LiAgVGhlcmUKICAgYXJlIHR3byBjbGFzc2VzIG9mIGNvbmZvcm1pbmcgaW1wbGVt ZW50YXRpb25zIGRlc2NyaWJlZCBieSB0aGlzCiAgIGRvY3VtZW50OiAid2VsbC1mb3JtZWQi IHByb2Nlc3NvcnMgYW5kICJ2YWxpZGF0aW5nIiBwcm9jZXNzb3JzLgogICBDbGFpbXMgb2Yg Y29uZm9ybWFuY2UgU0hPVUxEIGV4cGxpY2l0bHkgcmVmZXJlbmNlIG9uZSBvZiB0aGVzZQog ICBkZWZpbml0aW9ucy4KCiAgIEFuIGltcGxlbWVudGF0aW9uIHRoYXQgY2xhaW1zIHRvIGNo ZWNrIGZvciB3ZWxsLWZvcm1lZCBsYW5ndWFnZSB0YWdzCiAgIE1VU1Q6CgogICBvICBDaGVj ayB0aGF0IHRoZSB0YWcgYW5kIGFsbCBvZiBpdHMgc3VidGFncywgaW5jbHVkaW5nIGV4dGVu c2lvbiBhbmQKICAgICAgcHJpdmF0ZSB1c2Ugc3VidGFncywgY29uZm9ybSB0byB0aGUgQUJO RiBvciB0aGF0IHRoZSB0YWcgaXMgb24gdGhlCiAgICAgIGxpc3Qgb2YgZ3JhbmRmYXRoZXJl ZCB0YWdzLgoKICAgbyAgQ2hlY2sgdGhhdCBzaW5nbGV0b24gc3VidGFncyB0aGF0IGlkZW50 aWZ5IGV4dGVuc2lvbnMgZG8gbm90CiAgICAgIHJlcGVhdC4gIEZvciBleGFtcGxlLCB0aGUg dGFnICJlbi1hLXh4LWIteXktYS16eiIgaXMgbm90IHdlbGwtCiAgICAgIGZvcm1lZC4KCiAg IFdlbGwtZm9ybWVkIHByb2Nlc3NvcnMgYXJlIHN0cm9uZ2x5IGVuY291cmFnZWQgdG8gaW1w bGVtZW50IHRoZQogICBjYW5vbmljYWxpemF0aW9uIHJ1bGVzIGNvbnRhaW5lZCBpbiBTZWN0 aW9uIDQuNC4KCiAgIEFuIGltcGxlbWVudGF0aW9uIHRoYXQgY2xhaW1zIHRvIGJlIHZhbGlk YXRpbmcgTVVTVDoKCiAgIG8gIENoZWNrIHRoYXQgdGhlIHRhZyBpcyB3ZWxsLWZvcm1lZC4K CiAgIG8gIFNwZWNpZnkgdGhlIHBhcnRpY3VsYXIgcmVnaXN0cnkgZGF0ZSBmb3Igd2hpY2gg dGhlIGltcGxlbWVudGF0aW9uCiAgICAgIHBlcmZvcm1zIHZhbGlkYXRpb24gb2Ygc3VidGFn cy4KCiAgIG8gIENoZWNrIHRoYXQgZWl0aGVyIHRoZSB0YWcgaXMgYSBncmFuZGZhdGhlcmVk IHRhZywgb3IgdGhhdCBhbGwKICAgICAgbGFuZ3VhZ2UsIHNjcmlwdCwgcmVnaW9uLCBhbmQg dmFyaWFudCBzdWJ0YWdzIGNvbnNpc3Qgb2YgdmFsaWQKICAgICAgY29kZXMgZm9yIHVzZSBp biBsYW5ndWFnZSB0YWdzIGFjY29yZGluZyB0byB0aGUgSUFOQSByZWdpc3RyeSBhcwogICAg ICBvZiB0aGUgcGFydGljdWxhciBkYXRlIHNwZWNpZmllZCBieSB0aGUgaW1wbGVtZW50YXRp b24uCgogICBvICBTcGVjaWZ5IHdoaWNoLCBpZiBhbnksIGV4dGVuc2lvbiBSRkNzIGFzIGRl ZmluZWQgaW4gU2VjdGlvbiAzLjcKICAgICAgYXJlIHN1cHBvcnRlZCwgaW5jbHVkaW5nIHZl cnNpb24sIHJldmlzaW9uLCBhbmQgZGF0ZS4KCiAgIG8gIEZvciBhbnkgc3VjaCBleHRlbnNp b25zIHN1cHBvcnRlZCwgY2hlY2sgdGhhdCBhbGwgc3VidGFncyB1c2VkIGluCiAgICAgIHRo YXQgZXh0ZW5zaW9uIGFyZSB2YWxpZC4KCiAgIG8gIEZvciBleHRlbmRlZCBsYW5ndWFnZSBz dWJ0YWdzLCBjaGVjayB0aGF0IHRoZSB0YWcgbWF0Y2hlcyBhdCBsZWFzdAogICAgICBvbmUg J1ByZWZpeCcgZmllbGQgYXNzb2NpYXRlZCB3aXRoIHRoZSBzdWJ0YWcuICBUaGUgdGFnIG1h dGNoZXMgaWYKICAgICAgYWxsIHRoZSBzdWJ0YWdzIGluIHRoZSAnUHJlZml4JyBhbHNvIGFw cGVhciBpbiB0aGUgdGFnLiAgRm9yCiAgICAgIGV4YW1wbGUsIHRoZSBwcmVmaXggImVzLUNP IiBtYXRjaGVzIHRoZSB0YWcgImVzLUxhdG4tQ08teC1wcml2YXRlIgogICAgICBiZWNhdXNl IGJvdGggdGhlICdlcycgbGFuZ3VhZ2Ugc3VidGFnIGFuZCAnQ08nIHJlZ2lvbiBzdWJ0YWcK ICAgICAgYXBwZWFyIGluIHRoZSB0YWcuCgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAg RXhwaXJlcyBNYXJjaCAxNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAxN10KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg U2VwdGVtYmVyIDIwMDYKCgozLiAgUmVnaXN0cnkgRm9ybWF0IGFuZCBNYWludGVuYW5jZQoK ICAgVGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSBh bmQgdGhlIG1haW50ZW5hbmNlCiAgIGFuZCB1cGRhdGUgcHJvY2VkdXJlcyBhc3NvY2lhdGVk IHdpdGggaXQsIGFzIHdlbGwgYXMgYSByZWdpc3RyeSBmb3IKICAgZXh0ZW5zaW9ucyB0byBs YW5ndWFnZSB0YWdzIChTZWN0aW9uIDMuNykuCgogICBUaGUgTGFuZ3VhZ2UgU3VidGFnIFJl Z2lzdHJ5IGNvbnRhaW5zIGEgY29tcHJlaGVuc2l2ZSBsaXN0IG9mIGFsbCBvZgogICB0aGUg c3VidGFncyB2YWxpZCBpbiBsYW5ndWFnZSB0YWdzLiAgVGhpcyBhbGxvd3MgaW1wbGVtZW50 ZXJzIGEKICAgc3RyYWlnaHRmb3J3YXJkIGFuZCByZWxpYWJsZSB3YXkgdG8gdmFsaWRhdGUg bGFuZ3VhZ2UgdGFncy4gIFRoZQogICBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgd2lsbCBi ZSBtYWludGFpbmVkIHNvIHRoYXQsIGV4Y2VwdCBmb3IKICAgZXh0ZW5zaW9uIHN1YnRhZ3Ms IGl0IGlzIHBvc3NpYmxlIHRvIHZhbGlkYXRlIGFsbCBvZiB0aGUgc3VidGFncyB0aGF0CiAg IGFwcGVhciBpbiBhIGxhbmd1YWdlIHRhZyB1bmRlciB0aGUgcHJvdmlzaW9ucyBvZiB0aGlz IGRvY3VtZW50IG9yIGl0cwogICByZXZpc2lvbnMgb3Igc3VjY2Vzc29ycy4gIEluIGFkZGl0 aW9uLCB0aGUgbWVhbmluZyBvZiB0aGUgdmFyaW91cwogICBzdWJ0YWdzIHdpbGwgYmUgdW5h bWJpZ3VvdXMgYW5kIHN0YWJsZSBvdmVyIHRpbWUuICAoVGhlIG1lYW5pbmcgb2YKICAgcHJp dmF0ZSB1c2Ugc3VidGFncywgb2YgY291cnNlLCBpcyBub3QgZGVmaW5lZCBieSB0aGUgSUFO QSByZWdpc3RyeS4pCgozLjEuICBGb3JtYXQgb2YgdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFn IFJlZ2lzdHJ5CgogICBUaGUgSUFOQSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgKCJ0aGUg cmVnaXN0cnkiKSBjb25zaXN0cyBvZiBhIHRleHQKICAgZmlsZSB0aGF0IGlzIG1hY2hpbmUg cmVhZGFibGUgaW4gdGhlIGZvcm1hdCBkZXNjcmliZWQgaW4gdGhpcwogICBzZWN0aW9uLCBw bHVzIGNvcGllcyBvZiB0aGUgcmVnaXN0cmF0aW9uIGZvcm1zIGFwcHJvdmVkIGluIGFjY29y ZGFuY2UKICAgd2l0aCB0aGUgcHJvY2VzcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjUuICBU aGUgZXhpc3RpbmcgcmVnaXN0cmF0aW9uCiAgIGZvcm1zIGZvciBncmFuZGZhdGhlcmVkIGFu ZCByZWR1bmRhbnQgdGFncyB0YWtlbiBmcm9tIFJGQyAzMDY2IHdpbGwKICAgYmUgbWFpbnRh aW5lZCBhcyBwYXJ0IG9mIHRoZSBvYnNvbGV0ZSBSRkMgMzA2NiByZWdpc3RyeS4gIFRoZQog ICByZW1haW5pbmcgc2V0IG9mIGluaXRpYWwgc3VidGFncyB3aWxsIG5vdCBoYXZlIHJlZ2lz dHJhdGlvbiBmb3JtcwogICBjcmVhdGVkIGZvciB0aGVtLgoKICAgVGhlIHJlZ2lzdHJ5IGlz IGluIHRoZSB0ZXh0IGZvcm1hdCBkZXNjcmliZWQgYmVsb3cuICBUaGlzIGZvcm1hdCB3YXMK ICAgYmFzZWQgb24gdGhlIHJlY29yZC1qYXIgZm9ybWF0IGRlc2NyaWJlZCBpbiBbcmVjb3Jk LWphcl0uCgogICBFYWNoIGxpbmUgb2YgdGV4dCBpcyBsaW1pdGVkIHRvIDcyIGNoYXJhY3Rl cnMsIGluY2x1ZGluZyBhbGwKICAgd2hpdGVzcGFjZS4gIFJlY29yZHMgYXJlIHNlcGFyYXRl ZCBieSBsaW5lcyBjb250YWluaW5nIG9ubHkgdGhlCiAgIHNlcXVlbmNlICIlJSIgKCV4MjUu MjUpLgoKICAgRWFjaCBmaWVsZCBjYW4gYmUgdmlld2VkIGFzIGEgc2luZ2xlLCBsb2dpY2Fs IGxpbmUgb2YgQVNDSUkKICAgY2hhcmFjdGVycywgY29tcHJpc2luZyBhIGZpZWxkLW5hbWUg YW5kIGEgZmllbGQtYm9keSBzZXBhcmF0ZWQgYnkgYQogICBDT0xPTiBjaGFyYWN0ZXIgKCV4 M0EpLiAgRm9yIGNvbnZlbmllbmNlLCB0aGUgZmllbGQtYm9keSBwb3J0aW9uIG9mCiAgIHRo aXMgY29uY2VwdHVhbCBlbnRpdHkgY2FuIGJlIHNwbGl0IGludG8gYSBtdWx0aXBsZS1saW5l CiAgIHJlcHJlc2VudGF0aW9uOyB0aGlzIGlzIGNhbGxlZCAiZm9sZGluZyIuICBUaGUgZm9y bWF0IG9mIHRoZSByZWdpc3RyeQogICBpcyBkZXNjcmliZWQgYnkgdGhlIGZvbGxvd2luZyBB Qk5GIChwZXIgW1JGQzQyMzRdKToKCiAgIHJlZ2lzdHJ5ICAgPSByZWNvcmQgKigiJSUiIENS TEYgcmVjb3JkKQogICByZWNvcmQgICAgID0gMSooIGZpZWxkLW5hbWUgKlNQICI6IiAqU1Ag ZmllbGQtYm9keSBDUkxGICkKICAgZmllbGQtbmFtZSA9IChBTFBIQSAvIERJR0lUKSBbKihB TFBIQSAvIERJR0lUIC8gIi0iKSAoQUxQSEEgLyBESUdJVCldCiAgIGZpZWxkLWJvZHkgPSAq KEFTQ0NIQVIvTFdTUCkKICAgQVNDQ0hBUiAgICA9ICV4MjEtMjUgLyAleDI3LTdFIC8gVU5J Q0hBUiA7IE5vdGU6IEFNUEVSU0FORCBpcyAleDI2CiAgIFVOSUNIQVIgICAgPSAiJiN4IiAy KjZIRVhESUcgIjsiCgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJj aCAxNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAxOF0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIw MDYKCgogICBGaWd1cmUgMjogUmVnaXN0cnkgRm9ybWF0IEFCTkYKCiAgIFRoZSBzZXF1ZW5j ZSAnLi4nICgleDJFLjJFKSBpbiBhIGZpZWxkLWJvZHkgZGVub3RlcyBhIHJhbmdlIG9mCiAg IHZhbHVlcy4gIFN1Y2ggYSByYW5nZSByZXByZXNlbnRzIGFsbCBzdWJ0YWdzIG9mIHRoZSBz YW1lIGxlbmd0aCB0aGF0CiAgIGFyZSBpbiBhbHBoYWJldGljIG9yIG51bWVyaWMgb3JkZXIg d2l0aGluIHRoYXQgcmFuZ2UsIGluY2x1ZGluZyB0aGUKICAgdmFsdWVzIGV4cGxpY2l0bHkg bWVudGlvbmVkLiAgRm9yIGV4YW1wbGUgJ2EuLmMnIGRlbm90ZXMgdGhlIHZhbHVlcwogICAn YScsICdiJywgYW5kICdjJyBhbmQgJzExLi4xMycgZGVub3RlcyB0aGUgdmFsdWVzICcxMScs ICcxMicsIGFuZAogICAnMTMnLgoKICAgQ2hhcmFjdGVycyBmcm9tIG91dHNpZGUgdGhlIFVT LUFTQ0lJIFtJU082NDZdIHJlcGVydG9pcmUsIGFzIHdlbGwgYXMKICAgdGhlIEFNUEVSU0FO RCBjaGFyYWN0ZXIgKCImIiwgJXgyNikgd2hlbiBpdCBvY2N1cnMgaW4gYSBmaWVsZC1ib2R5 LAogICBhcmUgcmVwcmVzZW50ZWQgYnkgYSAiTnVtZXJpYyBDaGFyYWN0ZXIgUmVmZXJlbmNl IiB1c2luZyBoZXhhZGVjaW1hbAogICBub3RhdGlvbiBpbiB0aGUgc3R5bGUgdXNlZCBieSBb WE1MMTBdIChzZWUKICAgPGh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy14bWwvI2R0LWNoYXJy ZWY+KS4gIFRoaXMgY29uc2lzdHMgb2YgdGhlCiAgIHNlcXVlbmNlICImI3giICgleDI2LjIz Ljc4KSBmb2xsb3dlZCBieSBhIGhleGFkZWNpbWFsIHJlcHJlc2VudGF0aW9uCiAgIG9mIHRo ZSBjaGFyYWN0ZXIncyBjb2RlIHBvaW50IGluIFtJU08xMDY0Nl0gZm9sbG93ZWQgYnkgYSBj bG9zaW5nCiAgIHNlbWljb2xvbiAoJXgzQikuICBGb3IgZXhhbXBsZSwgdGhlIEVVUk8gU0lH TiwgVSsyMEFDLCB3b3VsZCBiZQogICByZXByZXNlbnRlZCBieSB0aGUgc2VxdWVuY2UgIiYj eDIwQUM7Ii4gIE5vdGUgdGhhdCB0aGUgaGV4YWRlY2ltYWwKICAgbm90YXRpb24gTUFZIGhh dmUgYmV0d2VlbiB0d28gYW5kIHNpeCBkaWdpdHMuCgogICBBbGwgZmllbGRzIHdob3NlIGZp ZWxkLWJvZHkgY29udGFpbnMgYSBkYXRlIHZhbHVlIHVzZSB0aGUgImZ1bGwtZGF0ZSIKICAg Zm9ybWF0IHNwZWNpZmllZCBpbiBbUkZDMzMzOV0uICBGb3IgZXhhbXBsZTogIjIwMDQtMDYt MjgiIHJlcHJlc2VudHMKICAgSnVuZSAyOCwgMjAwNCwgaW4gdGhlIEdyZWdvcmlhbiBjYWxl bmRhci4KCiAgIFRoZSBmaXJzdCByZWNvcmQgaW4gdGhlIGZpbGUgY29udGFpbnMgdGhlIHNp bmdsZSBmaWVsZCB3aG9zZSBmaWVsZC0KICAgbmFtZSBpcyAiRmlsZS1EYXRlIiAoc2VlIEZp Z3VyZSAyKS4gIFRoZSBmaWVsZC1ib2R5IG9mIHRoaXMgcmVjb3JkCiAgIGNvbnRhaW5zIHRo ZSBsYXN0IG1vZGlmaWNhdGlvbiBkYXRlIG9mIHRoaXMgY29weSBvZiB0aGUgcmVnaXN0cnks CiAgIG1ha2luZyBpdCBwb3NzaWJsZSB0byBjb21wYXJlIGRpZmZlcmVudCB2ZXJzaW9ucyBv ZiB0aGUgcmVnaXN0cnkuCiAgIFRoZSByZWdpc3RyeSBvbiB0aGUgSUFOQSB3ZWJzaXRlIGlz IHRoZSBtb3N0IGN1cnJlbnQuICBWZXJzaW9ucyB3aXRoCiAgIGFuIG9sZGVyIGRhdGUgdGhh biB0aGF0IG9uZSBhcmUgbm90IHVwLXRvLWRhdGUuCgogICBGaWxlLURhdGU6IDIwMDQtMDYt MjgKICAgJSUKCiAgIEZpZ3VyZSAzOiBFeGFtcGxlIG9mIHRoZSBGaWxlLURhdGUgUmVjb3Jk CgogICBTdWJzZXF1ZW50IHJlY29yZHMgcmVwcmVzZW50IHN1YnRhZ3MgaW4gdGhlIHJlZ2lz dHJ5LiAgRWFjaCBvZiB0aGUKICAgZmllbGRzIGluIGVhY2ggcmVjb3JkIE1VU1Qgb2NjdXIg bm8gbW9yZSB0aGFuIG9uY2UsIHVubGVzcyBvdGhlcndpc2UKICAgbm90ZWQgYmVsb3cuICBF YWNoIHJlY29yZCBNVVNUIGNvbnRhaW4gdGhlIGZvbGxvd2luZyBmaWVsZHM6CgogICBvICAn VHlwZScKCiAgICAgICogIFR5cGUncyBmaWVsZC12YWx1ZSBNVVNUIGNvbnNpc3Qgb2Ygb25l IG9mIHRoZSBmb2xsb3dpbmcKICAgICAgICAgc3RyaW5nczogImxhbmd1YWdlIiwgImV4dGxh bmciLCAic2NyaXB0IiwgInJlZ2lvbiIsICJ2YXJpYW50IiwKICAgICAgICAgImdyYW5kZmF0 aGVyZWQiLCBhbmQgInJlZHVuZGFudCIgYW5kIGRlbm90ZXMgdGhlIHR5cGUgb2YgdGFnIG9y CiAgICAgICAgIHN1YnRhZy4KCgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJl cyBNYXJjaCAxNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAxOV0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVt YmVyIDIwMDYKCgogICBvICBFaXRoZXIgJ1N1YnRhZycgb3IgJ1RhZycKCiAgICAgICogIFN1 YnRhZydzIGZpZWxkLXZhbHVlIGNvbnRhaW5zIHRoZSBzdWJ0YWcgYmVpbmcgZGVmaW5lZC4g IFRoaXMKICAgICAgICAgZmllbGQgTVVTVCBvbmx5IGFwcGVhciBpbiByZWNvcmRzIG9mIHdo b3NlICdUeXBlJyBoYXMgb25lIG9mCiAgICAgICAgIHRoZXNlIHZhbHVlczogImxhbmd1YWdl IiwgImV4dGxhbmciLCAic2NyaXB0IiwgInJlZ2lvbiIsIG9yCiAgICAgICAgICJ2YXJpYW50 Ii4KCiAgICAgICogIFRhZydzIGZpZWxkLXZhbHVlIGNvbnRhaW5zIGEgY29tcGxldGUgbGFu Z3VhZ2UgdGFnLiAgVGhpcyBmaWVsZAogICAgICAgICBNVVNUIG9ubHkgYXBwZWFyIGluIHJl Y29yZHMgd2hvc2UgJ1R5cGUnIGhhcyBvbmUgb2YgdGhlc2UKICAgICAgICAgdmFsdWVzOiAi Z3JhbmRmYXRoZXJlZCIgb3IgInJlZHVuZGFudCIuICBOb3RlIHRoYXQgdGhlIGZpZWxkLQog ICAgICAgICB2YWx1ZSB3aWxsIGFsd2F5cyBmb2xsb3cgdGhlICdncmFuZGZhdGhlcmVkJyBw cm9kdWN0aW9uIGluIHRoZQogICAgICAgICBBQk5GIGluIFNlY3Rpb24gMi4xCgogICBvICBE ZXNjcmlwdGlvbgoKICAgICAgKiAgRGVzY3JpcHRpb24ncyBmaWVsZC12YWx1ZSBjb250YWlu cyBhIG5vbi1ub3JtYXRpdmUgZGVzY3JpcHRpb24KICAgICAgICAgb2YgdGhlIHN1YnRhZyBv ciB0YWcuCgogICBvICBBZGRlZAoKICAgICAgKiAgQWRkZWQncyBmaWVsZC12YWx1ZSBjb250 YWlucyB0aGUgZGF0ZSB0aGUgcmVjb3JkIHdhcyBhZGRlZCB0bwogICAgICAgICB0aGUgcmVn aXN0cnkuCgogICBUaGUgJ1N1YnRhZycgb3IgJ1RhZycgZmllbGQgTVVTVCB1c2UgbG93ZXJj YXNlIGxldHRlcnMgdG8gZm9ybSB0aGUKICAgc3VidGFnIG9yIHRhZywgd2l0aCB0d28gZXhj ZXB0aW9ucy4gIFN1YnRhZ3Mgd2hvc2UgJ1R5cGUnIGZpZWxkIGlzCiAgICdzY3JpcHQnIChp biBvdGhlciB3b3Jkcywgc3VidGFncyBkZWZpbmVkIGJ5IElTTyAxNTkyNCkgTVVTVCB1c2UK ICAgdGl0bGVjYXNlLiAgU3VidGFncyB3aG9zZSAnVHlwZScgZmllbGQgaXMgJ3JlZ2lvbicg KGluIG90aGVyIHdvcmRzLAogICBzdWJ0YWdzIGRlZmluZWQgYnkgSVNPIDMxNjYpIE1VU1Qg dXNlIHVwcGVyY2FzZS4gIFRoZXNlIGV4Y2VwdGlvbnMKICAgbWlycm9yIHRoZSB1c2Ugb2Yg Y2FzZSBpbiB0aGUgdW5kZXJseWluZyBzdGFuZGFyZHMuCgogICBUaGUgZmllbGQgJ0Rlc2Ny aXB0aW9uJyBNQVkgYXBwZWFyIG1vcmUgdGhhbiBvbmUgdGltZSBhbmQgY29udGFpbnMgYQog ICBkZXNjcmlwdGlvbiBvZiB0aGUgdGFnIG9yIHN1YnRhZyBpbiB0aGUgcmVjb3JkLiAgQXQg bGVhc3Qgb25lIG9mIHRoZQogICAnRGVzY3JpcHRpb24nIGZpZWxkcyBNVVNUIGJlIHdyaXR0 ZW4gb3IgdHJhbnNjcmliZWQgaW50byB0aGUgTGF0aW4KICAgc2NyaXB0OyB0aGUgc2FtZSBv ciBhZGRpdGlvbmFsIGZpZWxkcyBNQVkgYWxzbyBpbmNsdWRlIGEgZGVzY3JpcHRpb24KICAg aW4gYSBub24tTGF0aW4gc2NyaXB0LiAgVGhlICdEZXNjcmlwdGlvbicgZmllbGQgaXMgdXNl ZCBmb3IKICAgaWRlbnRpZmljYXRpb24gcHVycG9zZXMgYW5kIFNIT1VMRCBOT1QgYmUgdGFr ZW4gdG8gcmVwcmVzZW50IHRoZQogICBhY3R1YWwgbmF0aXZlIG5hbWUgb2YgdGhlIGxhbmd1 YWdlIG9yIHZhcmlhdGlvbiBvciB0byBiZSBpbiBhbnkKICAgcGFydGljdWxhciBsYW5ndWFn ZS4gIE1vc3QgZGVzY3JpcHRpb25zIGFyZSB0YWtlbiBkaXJlY3RseSBmcm9tCiAgIHNvdXJj ZSBzdGFuZGFyZHMgc3VjaCBhcyBJU08gNjM5IG9yIElTTyAzMTY2LgoKICAgTm90ZTogRGVz Y3JpcHRpb25zIGluIHJlZ2lzdHJ5IGVudHJpZXMgdGhhdCBjb3JyZXNwb25kIHRvIElTTyA2 MzksCiAgIElTTyAxNTkyNCwgSVNPIDMxNjYsIG9yIFVOIE0uNDkgY29kZXMgYXJlIGludGVu ZGVkIG9ubHkgdG8gaW5kaWNhdGUKICAgdGhlIG1lYW5pbmcgb2YgdGhhdCBpZGVudGlmaWVy IGFzIGRlZmluZWQgaW4gdGhlIHNvdXJjZSBzdGFuZGFyZCBhdAogICB0aGUgdGltZSBpdCB3 YXMgYWRkZWQgdG8gdGhlIHJlZ2lzdHJ5LiAgVGhlIGRlc2NyaXB0aW9uIGRvZXMgbm90CiAg IHJlcGxhY2UgdGhlIGNvbnRlbnQgb2YgdGhlIHNvdXJjZSBzdGFuZGFyZCBpdHNlbGYuICBU aGUgZGVzY3JpcHRpb25zCiAgIGFyZSBub3QgaW50ZW5kZWQgdG8gYmUgdGhlIEVuZ2xpc2gg bG9jYWxpemVkIG5hbWVzIGZvciB0aGUgc3VidGFncy4KICAgTG9jYWxpemF0aW9uIG9yIHRy YW5zbGF0aW9uIG9mIGxhbmd1YWdlIHRhZyBhbmQgc3VidGFnIGRlc2NyaXB0aW9ucwogICBp cyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4KCgoKUGhpbGxpcHMgJiBEYXZpcyAg ICAgICAgIEV4cGlyZXMgTWFyY2ggMTUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMjBd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgIFNlcHRlbWJlciAyMDA2CgoKICAgRWFjaCByZWNvcmQgTUFZIGFsc28gY29udGFp biB0aGUgZm9sbG93aW5nIGZpZWxkczoKCiAgIG8gIFByZWZlcnJlZC1WYWx1ZQoKICAgICAg KiAgRm9yIGZpZWxkcyBvZiB0eXBlICdsYW5ndWFnZScsICdleHRsYW5nJywgJ3NjcmlwdCcs ICdyZWdpb24nLAogICAgICAgICBhbmQgJ3ZhcmlhbnQnLCAnUHJlZmVycmVkLVZhbHVlJyBj b250YWlucyB0aGUgc3VidGFnIG9mIHRoZQogICAgICAgICBzYW1lICdUeXBlJyB0aGF0IGlz IHByZWZlcnJlZCBmb3IgZm9ybWluZyB0aGUgbGFuZ3VhZ2UgdGFnLgoKICAgICAgKiAgRm9y IGZpZWxkcyBvZiB0eXBlICdncmFuZGZhdGhlcmVkJyBhbmQgJ3JlZHVuZGFudCcsIGEgY2Fu b25pY2FsCiAgICAgICAgIG1hcHBpbmcgdG8gYSBjb21wbGV0ZSBsYW5ndWFnZSB0YWcuCgog ICBvICBEZXByZWNhdGVkCgogICAgICAqICBEZXByZWNhdGVkJ3MgZmllbGQtdmFsdWUgY29u dGFpbnMgdGhlIGRhdGUgdGhlIHJlY29yZCB3YXMKICAgICAgICAgZGVwcmVjYXRlZC4KCiAg IG8gIFByZWZpeAoKICAgICAgKiAgUHJlZml4J3MgZmllbGQtdmFsdWUgY29udGFpbnMgYSBs YW5ndWFnZSB0YWcgd2l0aCB3aGljaCB0aGlzCiAgICAgICAgIHN1YnRhZyBNQVkgYmUgdXNl ZCB0byBmb3JtIGEgbmV3IGxhbmd1YWdlIHRhZywgcGVyaGFwcyB3aXRoCiAgICAgICAgIG90 aGVyIHN1YnRhZ3MgYXMgd2VsbC4gIFRoaXMgZmllbGQgTVVTVCBvbmx5IGFwcGVhciBpbiBy ZWNvcmRzCiAgICAgICAgIHdob3NlICdUeXBlJyBmaWVsZC12YWx1ZSBpcyAndmFyaWFudCcg b3IgJ2V4dGxhbmcnLiAgRm9yCiAgICAgICAgIGV4YW1wbGUsIHRoZSAnUHJlZml4JyBmb3Ig dGhlIHZhcmlhbnQgJ25lZGlzJyBpcyAnc2wnLCBtZWFuaW5nCiAgICAgICAgIHRoYXQgdGhl IHRhZ3MgInNsLW5lZGlzIiBhbmQgInNsLUlULW5lZGlzIiBtaWdodCBiZSBhcHByb3ByaWF0 ZQogICAgICAgICB3aGlsZSB0aGUgdGFnICJpcy1uZWRpcyIgaXMgbm90LgoKICAgbyAgQ29t bWVudHMKCiAgICAgICogIENvbW1lbnRzIGNvbnRhaW5zIGFkZGl0aW9uYWwgaW5mb3JtYXRp b24gYWJvdXQgdGhlIHN1YnRhZywgYXMKICAgICAgICAgZGVlbWVkIGFwcHJvcHJpYXRlIGZv ciB1bmRlcnN0YW5kaW5nIHRoZSByZWdpc3RyeSBhbmQKICAgICAgICAgaW1wbGVtZW50aW5n IGxhbmd1YWdlIHRhZ3MgdXNpbmcgdGhlIHN1YnRhZyBvciB0YWcuCgogICBvICBTdXBwcmVz cy1TY3JpcHQKCiAgICAgICogIFN1cHByZXNzLVNjcmlwdCBjb250YWlucyBhIHNjcmlwdCBz dWJ0YWcgdGhhdCBTSE9VTEQgTk9UIGJlCiAgICAgICAgIHVzZWQgdG8gZm9ybSBsYW5ndWFn ZSB0YWdzIHdpdGggdGhlIGFzc29jaWF0ZWQgcHJpbWFyeSBsYW5ndWFnZQogICAgICAgICBz dWJ0YWcuICBUaGlzIGZpZWxkIE1VU1Qgb25seSBhcHBlYXIgaW4gcmVjb3JkcyB3aG9zZSAn VHlwZScKICAgICAgICAgZmllbGQtdmFsdWUgaXMgJ2xhbmd1YWdlJy4gIFNlZSBTZWN0aW9u IDQuMS4KCiAgIFRoZSBmaWVsZCAnRGVwcmVjYXRlZCcgTUFZIGJlIGFkZGVkIHRvIGFueSBy ZWNvcmQgdmlhIHRoZSBtYWludGVuYW5jZQogICBwcm9jZXNzIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDMuMyBvciB2aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzCiAgIGRlc2NyaWJlZCBp biBTZWN0aW9uIDMuNS4gIFVzdWFsbHksIHRoZSBhZGRpdGlvbiBvZiBhICdEZXByZWNhdGVk JwogICBmaWVsZCBpcyBkdWUgdG8gdGhlIGFjdGlvbiBvZiBvbmUgb2YgdGhlIHN0YW5kYXJk cyBib2RpZXMsIHN1Y2ggYXMKICAgSVNPIDMxNjYsIHdpdGhkcmF3aW5nIGEgY29kZS4gIElu IHNvbWUgaGlzdG9yaWNhbCBjYXNlcywgaXQgbWlnaHQgbm90CiAgIGhhdmUgYmVlbiBwb3Nz aWJsZSB0byByZWNvbnN0cnVjdCB0aGUgb3JpZ2luYWwgZGVwcmVjYXRpb24gZGF0ZS4gIEZv cgogICB0aGVzZSBjYXNlcywgYW4gYXBwcm94aW1hdGUgZGF0ZSBhcHBlYXJzIGluIHRoZSBy ZWdpc3RyeS4gIEFsdGhvdWdoCiAgIHZhbGlkIGluIGxhbmd1YWdlIHRhZ3MsIHN1YnRhZ3Mg YW5kIHRhZ3Mgd2l0aCBhICdEZXByZWNhdGVkJyBmaWVsZAogICBhcmUgZGVwcmVjYXRlZCBh bmQgdmFsaWRhdGluZyBwcm9jZXNzb3JzIFNIT1VMRCBOT1QgZ2VuZXJhdGUgdGhlc2UKCgoK UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMTUsIDIwMDcgICAgICAg ICAgICAgICAgW1BhZ2UgMjFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0 YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA2CgoKICAgc3VidGFncy4g IE5vdGUgdGhhdCBhIHJlY29yZCB0aGF0IGNvbnRhaW5zIGEgJ0RlcHJlY2F0ZWQnIGZpZWxk IGFuZAogICBubyBjb3JyZXNwb25kaW5nICdQcmVmZXJyZWQtVmFsdWUnIGZpZWxkIGhhcyBu byByZXBsYWNlbWVudCBtYXBwaW5nLgoKICAgVGhlIGZpZWxkICdQcmVmZXJyZWQtVmFsdWUn IGNvbnRhaW5zIGEgbWFwcGluZyBiZXR3ZWVuIHRoZSByZWNvcmQgaW4KICAgd2hpY2ggaXQg YXBwZWFycyBhbmQgYW5vdGhlciB0YWcgb3Igc3VidGFnLiAgVGhlIHZhbHVlIGluIHRoaXMg ZmllbGQKICAgaXMgU1RST05HTFkgUkVDT01NRU5ERUQgYXMgdGhlIGJlc3QgY2hvaWNlIHRv IHJlcHJlc2VudCB0aGUgdmFsdWUgb2YKICAgdGhpcyByZWNvcmQgd2hlbiBzZWxlY3Rpbmcg YSBsYW5ndWFnZSB0YWcuICBUaGVzZSB2YWx1ZXMgZm9ybSB0aHJlZQogICBncm91cHM6Cgog ICAxLiAgSVNPIDYzOSBsYW5ndWFnZSBjb2RlcyB0aGF0IHdlcmUgbGF0ZXIgd2l0aGRyYXdu IGluIGZhdm9yIG9mCiAgICAgICBvdGhlciBjb2Rlcy4gIFRoZXNlIHZhbHVlcyBhcmUgbW9z dGx5IGEgaGlzdG9yaWNhbCBjdXJpb3NpdHkuCgogICAyLiAgSVNPIDMxNjYgcmVnaW9uIGNv ZGVzIHRoYXQgaGF2ZSBiZWVuIHdpdGhkcmF3biBpbiBmYXZvciBvZiBhIG5ldwogICAgICAg Y29kZS4gIFRoaXMgc29tZXRpbWVzIGhhcHBlbnMgd2hlbiBhIGNvdW50cnkgY2hhbmdlcyBp dHMgbmFtZSBvcgogICAgICAgYWRtaW5pc3RyYXRpb24gaW4gc3VjaCBhIHdheSB0aGF0IHdh cnJhbnRzIGEgbmV3IHJlZ2lvbiBjb2RlLgoKICAgMy4gIFRhZ3MgZ3JhbmRmYXRoZXJlZCBm cm9tIFJGQyAzMDY2LiAgSW4gbWFueSBjYXNlcywgdGhlc2UgdGFncyBoYXZlCiAgICAgICBi ZWNvbWUgb2Jzb2xldGUgYmVjYXVzZSB0aGUgdmFsdWVzIHRoZXkgcmVwcmVzZW50IHdlcmUg bGF0ZXIKICAgICAgIGVuY29kZWQgYnkgSVNPIDYzOS4KCiAgIFJlY29yZHMgdGhhdCBjb250 YWluIGEgJ1ByZWZlcnJlZC1WYWx1ZScgZmllbGQgTVVTVCBhbHNvIGhhdmUgYQogICAnRGVw cmVjYXRlZCcgZmllbGQuICBUaGlzIGZpZWxkIGNvbnRhaW5zIGEgZGF0ZSBvZiBkZXByZWNh dGlvbi4KICAgVGh1cywgYSBsYW5ndWFnZSB0YWcgcHJvY2Vzc29yIGNhbiB1c2UgdGhlIHJl Z2lzdHJ5IHRvIGNvbnN0cnVjdCB0aGUKICAgdmFsaWQsIG5vbi1kZXByZWNhdGVkIHNldCBv ZiBzdWJ0YWdzIGZvciBhIGdpdmVuIGRhdGUuICBJbiBhZGRpdGlvbiwKICAgZm9yIGFueSBn aXZlbiB0YWcsIGEgcHJvY2Vzc29yIGNhbiBjb25zdHJ1Y3QgdGhlIHNldCBvZiB2YWxpZAog ICBsYW5ndWFnZSB0YWdzIHRoYXQgY29ycmVzcG9uZCB0byB0aGF0IHRhZyBmb3IgYWxsIGRh dGVzIHVwIHRvIHRoZQogICBkYXRlIG9mIHRoZSByZWdpc3RyeS4gIFRoZSBhYmlsaXR5IHRv IGRvIHRoZXNlIG1hcHBpbmdzIE1BWSBiZQogICBiZW5lZmljaWFsIHRvIGFwcGxpY2F0aW9u cyB0aGF0IGFyZSBtYXRjaGluZywgc2VsZWN0aW5nLCBmb3IKICAgZmlsdGVyaW5nIGNvbnRl bnQgYmFzZWQgb24gaXRzIGxhbmd1YWdlIHRhZ3MuCgogICBOb3RlIHRoYXQgJ1ByZWZlcnJl ZC1WYWx1ZScgbWFwcGluZ3MgaW4gcmVjb3JkcyBvZiB0eXBlICdyZWdpb24nCiAgIHNvbWV0 aW1lcyBkbyBub3QgcmVwcmVzZW50IGV4YWN0bHkgdGhlIHNhbWUgbWVhbmluZyBhcyB0aGUg b3JpZ2luYWwKICAgdmFsdWUuICBUaGVyZSBhcmUgbWFueSByZWFzb25zIGZvciBhIGNvdW50 cnkgY29kZSB0byBiZSBjaGFuZ2VkLCBhbmQKICAgdGhlIGVmZmVjdCB0aGlzIGhhcyBvbiB0 aGUgZm9ybWF0aW9uIG9mIGxhbmd1YWdlIHRhZ3Mgd2lsbCBkZXBlbmQgb24KICAgdGhlIG5h dHVyZSBvZiB0aGUgY2hhbmdlIGluIHF1ZXN0aW9uLgoKICAgSW4gcGFydGljdWxhciwgdGhl ICdQcmVmZXJyZWQtVmFsdWUnIGZpZWxkIGRvZXMgbm90IGltcGx5IHJldGFnZ2luZwogICBj b250ZW50IHRoYXQgdXNlcyB0aGUgYWZmZWN0ZWQgc3VidGFnLgoKICAgVGhlIGZpZWxkICdQ cmVmZXJyZWQtVmFsdWUnIE1VU1QgTk9UIGJlIG1vZGlmaWVkIG9uY2UgY3JlYXRlZCBpbiB0 aGUKICAgcmVnaXN0cnkuICBUaGUgZmllbGQgTUFZIGJlIGFkZGVkIHRvIHJlY29yZHMgb2Yg dHlwZSAiZ3JhbmRmYXRoZXJlZCIKICAgYW5kICJyZWdpb24iIGFjY29yZGluZyB0byB0aGUg cnVsZXMgaW4gU2VjdGlvbiAzLjMuICBPdGhlcndpc2UgdGhlCiAgIGZpZWxkIE1VU1QgTk9U IGJlIGFkZGVkIHRvIGFueSByZWNvcmQgYWxyZWFkeSBpbiB0aGUgcmVnaXN0cnkuCgogICBU aGUgJ1ByZWZlcnJlZC1WYWx1ZScgZmllbGQgaW4gcmVjb3JkcyBvZiB0eXBlICJncmFuZGZh dGhlcmVkIiBhbmQKICAgInJlZHVuZGFudCIgY29udGFpbnMgd2hvbGUgbGFuZ3VhZ2UgdGFn cyB0aGF0IGFyZSBzdHJvbmdseQogICBSRUNPTU1FTkRFRCBmb3IgdXNlIGluIHBsYWNlIG9m IHRoZSByZWNvcmQncyB2YWx1ZS4gIEluIG1hbnkgY2FzZXMsCiAgIHRoZSBtYXBwaW5ncyB3 ZXJlIGNyZWF0ZWQgYnkgZGVwcmVjYXRpb24gb2YgdGhlIHRhZ3MgZHVyaW5nIHRoZQoKCgpQ aGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAxNSwgMjAwNyAgICAgICAg ICAgICAgICBbUGFnZSAyMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3Rh Z3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDYKCgogICBwZXJpb2QgYmVm b3JlIHRoaXMgZG9jdW1lbnQgd2FzIGFkb3B0ZWQuICBGb3IgZXhhbXBsZSwgdGhlIHRhZyAi bm8tCiAgIG55biIgd2FzIGRlcHJlY2F0ZWQgaW4gZmF2b3Igb2YgdGhlIElTTyA2MzktMS1k ZWZpbmVkIGxhbmd1YWdlIGNvZGUKICAgJ25uJy4KCiAgIFJlY29yZHMgb2YgdHlwZSAndmFy aWFudCcgTUFZIGhhdmUgbW9yZSB0aGFuIG9uZSBmaWVsZCBvZiB0eXBlCiAgICdQcmVmaXgn LiAgQWRkaXRpb25hbCBmaWVsZHMgb2YgdGhpcyB0eXBlIE1BWSBiZSBhZGRlZCB0byBhICd2 YXJpYW50JwogICByZWNvcmQgdmlhIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcy4KCiAgIFJl Y29yZHMgb2YgdHlwZSAnZXh0bGFuZycgTVVTVCBoYXZlIF9leGFjdGx5XyBvbmUgJ1ByZWZp eCcgZmllbGQuCgogICBUaGUgZmllbGQtdmFsdWUgb2YgdGhlICdQcmVmaXgnIGZpZWxkIGNv bnNpc3RzIG9mIGEgbGFuZ3VhZ2UgdGFnCiAgIHdob3NlIHN1YnRhZ3MgYXJlIGFwcHJvcHJp YXRlIHRvIHVzZSB3aXRoIHRoaXMgc3VidGFnLiAgRm9yIGV4YW1wbGUsCiAgIHRoZSB2YXJp YW50IHN1YnRhZyAnMTk5NicgaGFzIGEgJ1ByZWZpeCcgZmllbGQgb2YgImRlIi4gIFRoaXMg bWVhbnMKICAgdGhhdCB0YWdzIHN0YXJ0aW5nIHdpdGggdGhlIHNlcXVlbmNlICJkZS0iIGFy ZSBhcHByb3ByaWF0ZSB3aXRoIHRoaXMKICAgc3VidGFnLCBzbyAiZGUtTGF0Zy0xOTk2IiBh bmQgImRlLUNILTE5OTYiIGFyZSBib3RoIGFjY2VwdGFibGUsIHdoaWxlCiAgIHRoZSB0YWcg ImZyLTE5OTYiIGlzIGFuIGluYXBwcm9wcmlhdGUgY2hvaWNlLgoKICAgVGhlIGZpZWxkIG9m IHR5cGUgJ1ByZWZpeCcgTVVTVCBOT1QgYmUgcmVtb3ZlZCBmcm9tIGFueSByZWNvcmQuICBU aGUKICAgZmllbGQtdmFsdWUgZm9yIHRoaXMgdHlwZSBvZiBmaWVsZCBNVVNUIE5PVCBiZSBt b2RpZmllZC4KCiAgIFRoZSBmaWVsZCAnQ29tbWVudHMnIE1BWSBhcHBlYXIgbW9yZSB0aGFu IG9uY2UgcGVyIHJlY29yZC4gIFRoaXMKICAgZmllbGQgTUFZIGJlIGluc2VydGVkIG9yIGNo YW5nZWQgdmlhIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBhbmQgbm8KICAgZ3VhcmFudGVl IG9mIHN0YWJpbGl0eSBpcyBwcm92aWRlZC4gIFRoZSBjb250ZW50IG9mIHRoaXMgZmllbGQg aXMgbm90CiAgIHJlc3RyaWN0ZWQsIGV4Y2VwdCBieSB0aGUgbmVlZCB0byByZWdpc3RlciB0 aGUgaW5mb3JtYXRpb24sIHRoZQogICBzdWl0YWJpbGl0eSBvZiB0aGUgcmVxdWVzdCwgYW5k IGJ5IHJlYXNvbmFibGUgcHJhY3RpY2FsIHNpemUKICAgbGltaXRhdGlvbnMuCgogICBUaGUg ZmllbGQgJ1N1cHByZXNzLVNjcmlwdCcgTVVTVCBvbmx5IGFwcGVhciBpbiByZWNvcmRzIHdo b3NlICdUeXBlJwogICBmaWVsZC12YWx1ZSBpcyAnbGFuZ3VhZ2UnLiAgVGhpcyBmaWVsZCBN VVNUIE5PVCBhcHBlYXIgbW9yZSB0aGFuIG9uZQogICB0aW1lIGluIGEgcmVjb3JkLiAgVGhp cyBmaWVsZCBpbmRpY2F0ZXMgYSBzY3JpcHQgdXNlZCB0byB3cml0ZSB0aGUKICAgb3Zlcndo ZWxtaW5nIG1ham9yaXR5IG9mIGRvY3VtZW50cyBmb3IgdGhlIGdpdmVuIGxhbmd1YWdlIGFu ZCB0aGF0CiAgIHRoZXJlZm9yZSBhZGRzIG5vIGRpc3Rpbmd1aXNoaW5nIGluZm9ybWF0aW9u IHRvIGEgbGFuZ3VhZ2UgdGFnLiAgSXQKICAgaGVscHMgZW5zdXJlIGdyZWF0ZXIgY29tcGF0 aWJpbGl0eSBiZXR3ZWVuIHRoZSBsYW5ndWFnZSB0YWdzCiAgIGdlbmVyYXRlZCBhY2NvcmRp bmcgdG8gdGhlIHJ1bGVzIGluIHRoaXMgZG9jdW1lbnQgYW5kIGxhbmd1YWdlIHRhZ3MKICAg YW5kIHRhZyBwcm9jZXNzb3JzIG9yIGNvbnN1bWVycyBiYXNlZCBvbiBSRkMgMzA2Ni4gIEZv ciBleGFtcGxlLAogICB2aXJ0dWFsbHkgYWxsIEljZWxhbmRpYyBkb2N1bWVudHMgYXJlIHdy aXR0ZW4gaW4gdGhlIExhdGluIHNjcmlwdCwKICAgbWFraW5nIHRoZSBzdWJ0YWcgJ0xhdG4n IHJlZHVuZGFudCBpbiB0aGUgdGFnICJpcy1MYXRuIi4KCjMuMi4gIExhbmd1YWdlIFN1YnRh ZyBSZXZpZXdlcgoKICAgVGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBpcyBhcHBvaW50 ZWQgYnkgdGhlIElFU0cgZm9yIGFuCiAgIGluZGVmaW5pdGUgdGVybSwgc3ViamVjdCB0byBy ZW1vdmFsIG9yIHJlcGxhY2VtZW50IGF0IHRoZSBJRVNHJ3MKICAgZGlzY3JldGlvbi4gIFRo ZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgbW9kZXJhdGVzIHRoZSBpZXRmLQogICBsYW5n dWFnZXMgbWFpbGluZyBsaXN0LCByZXNwb25kcyB0byByZXF1ZXN0cyBmb3IgcmVnaXN0cmF0 aW9uLCBhbmQKICAgcGVyZm9ybXMgdGhlIG90aGVyIHJlZ2lzdHJ5IG1haW50ZW5hbmNlIGR1 dGllcyBkZXNjcmliZWQgaW4KICAgU2VjdGlvbiAzLjMuICBPbmx5IHRoZSBMYW5ndWFnZSBT dWJ0YWcgUmV2aWV3ZXIgaXMgcGVybWl0dGVkIHRvCiAgIHJlcXVlc3QgSUFOQSB0byBjaGFu Z2UsIHVwZGF0ZSwgb3IgYWRkIHJlY29yZHMgdG8gdGhlIExhbmd1YWdlIFN1YnRhZwogICBS ZWdpc3RyeS4KCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMTUs IDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMjNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA2CgoK ICAgVGhlIHBlcmZvcm1hbmNlIG9yIGRlY2lzaW9ucyBvZiB0aGUgTGFuZ3VhZ2UgU3VidGFn IFJldmlld2VyIE1BWSBiZQogICBhcHBlYWxlZCB0byB0aGUgSUVTRyB1bmRlciB0aGUgc2Ft ZSBydWxlcyBhcyBvdGhlciBJRVRGIGRlY2lzaW9ucwogICAoc2VlIFtSRkMyMDI2XSkuICBU aGUgSUVTRyBjYW4gcmV2ZXJzZSBvciBvdmVydHVybiB0aGUgZGVjaXNpb24gb2YKICAgdGhl IExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciwgcHJvdmlkZSBndWlkYW5jZSwgb3IgdGFrZSBv dGhlcgogICBhcHByb3ByaWF0ZSBhY3Rpb25zLgoKMy4zLiAgTWFpbnRlbmFuY2Ugb2YgdGhl IFJlZ2lzdHJ5CgogICBNYWludGVuYW5jZSBvZiB0aGUgcmVnaXN0cnkgcmVxdWlyZXMgdGhh dCBhcyBjb2RlcyBhcmUgYXNzaWduZWQgb3IKICAgd2l0aGRyYXduIGJ5IElTTyA2MzksIElT TyAxNTkyNCwgSVNPIDMxNjYsIGFuZCBVTiBNLjQ5LCB0aGUgTGFuZ3VhZ2UKICAgU3VidGFn IFJldmlld2VyIE1VU1QgZXZhbHVhdGUgZWFjaCBjaGFuZ2UsIGRldGVybWluZSB3aGV0aGVy IGl0CiAgIGNvbmZsaWN0cyB3aXRoIGV4aXN0aW5nIHJlZ2lzdHJ5IGVudHJpZXMsIGFuZCBz dWJtaXQgdGhlIGluZm9ybWF0aW9uCiAgIHRvIElBTkEgZm9yIGluY2x1c2lvbiBpbiB0aGUg cmVnaXN0cnkuICBJZiBhIGNoYW5nZSB0YWtlcyBwbGFjZSBhbmQKICAgdGhlIExhbmd1YWdl IFN1YnRhZyBSZXZpZXdlciBkb2VzIG5vdCBkbyB0aGlzIGluIGEgdGltZWx5IG1hbm5lciwK ICAgdGhlbiBhbnkgaW50ZXJlc3RlZCBwYXJ0eSBNQVkgdXNlIHRoZSBwcm9jZWR1cmUgaW4g U2VjdGlvbiAzLjUgdG8KICAgcmVnaXN0ZXIgdGhlIGFwcHJvcHJpYXRlIHVwZGF0ZS4KCiAg IE5vdGU6IFRoZSByZWR1bmRhbnQgYW5kIGdyYW5kZmF0aGVyZWQgZW50cmllcyB0b2dldGhl ciBhcmUgdGhlCiAgIGNvbXBsZXRlIGxpc3Qgb2YgdGFncyByZWdpc3RlcmVkIHVuZGVyIFtS RkMzMDY2XS4gIFRoZSByZWR1bmRhbnQgdGFncwogICBhcmUgdGhvc2UgdGhhdCBjYW4gbm93 IGJlIGZvcm1lZCB1c2luZyB0aGUgc3VidGFncyBkZWZpbmVkIGluIHRoZQogICByZWdpc3Ry eSB0b2dldGhlciB3aXRoIHRoZSBydWxlcyBvZiBTZWN0aW9uIDIuMi4gIFRoZSBncmFuZGZh dGhlcmVkCiAgIGVudHJpZXMgaW5jbHVkZSB0aG9zZSB0aGF0IGNhbiBuZXZlciBiZSBsZWdh bCB1bmRlciB0aG9zZSBzYW1lCiAgIHByb3Zpc2lvbnMgcGx1cyB0aG9zZSB0YWdzIHRoYXQg Y29udGFpbiBzdWJ0YWdzIG5vdCB5ZXQgcmVnaXN0ZXJlZAogICBvciwgcGVyaGFwcywgaW5h cHByb3ByaWF0ZSBmb3IgcmVnaXN0cmF0aW9uLgoKICAgVGhlIHNldCBvZiByZWR1bmRhbnQg YW5kIGdyYW5kZmF0aGVyZWQgdGFncyBpcyBwZXJtYW5lbnQgYW5kIHN0YWJsZToKICAgbmV3 IGVudHJpZXMgaW4gdGhpcyBzZWN0aW9uIE1VU1QgTk9UIGJlIGFkZGVkIGFuZCBleGlzdGlu ZyBlbnRyaWVzCiAgIE1VU1QgTk9UIGJlIHJlbW92ZWQuICBSZWNvcmRzIG9mIHR5cGUgJ2dy YW5kZmF0aGVyZWQnIE1BWSBoYXZlIHRoZWlyCiAgIHR5cGUgY29udmVydGVkIHRvICdyZWR1 bmRhbnQnOyBzZWUgaXRlbSAxMiBpbiBTZWN0aW9uIDMuNiBmb3IgbW9yZQogICBpbmZvcm1h dGlvbi4gIFRoZSBkZWNpc2lvbi1tYWtpbmcgcHJvY2VzcyBhYm91dCB3aGljaCB0YWdzIHdl cmUKICAgaW5pdGlhbGx5IGdyYW5kZmF0aGVyZWQgYW5kIHdoaWNoIHdlcmUgbWFkZSByZWR1 bmRhbnQgaXMgZGVzY3JpYmVkIGluCiAgIFtpbml0aWFsLXJlZ2lzdHJ5XS4KCiAgIFJGQyAz MDY2IHRhZ3MgdGhhdCB3ZXJlIGRlcHJlY2F0ZWQgcHJpb3IgdG8gdGhlIGFkb3B0aW9uIG9m IFtSRkM0NjQ2XQogICBhcmUgcGFydCBvZiB0aGUgbGlzdCBvZiBncmFuZGZhdGhlcmVkIHRh Z3MsIGFuZCB0aGVpciBjb21wb25lbnQKICAgc3VidGFncyB3ZXJlIG5vdCBpbmNsdWRlZCBh cyByZWdpc3RlcmVkIHZhcmlhbnRzIChhbHRob3VnaCB0aGV5CiAgIHJlbWFpbiBlbGlnaWJs ZSBmb3IgcmVnaXN0cmF0aW9uKS4gIEZvciBleGFtcGxlLCB0aGUgdGFnICJhcnQtbG9qYmFu IgogICB3YXMgZGVwcmVjYXRlZCBpbiBmYXZvciBvZiB0aGUgbGFuZ3VhZ2Ugc3VidGFnICdq Ym8nLgoKICAgVGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBNVVNUIGVuc3VyZSB0aGF0 IG5ldyBzdWJ0YWdzIG1lZXQgdGhlCiAgIHJlcXVpcmVtZW50cyBpbiBTZWN0aW9uIDQuMSBv ciBzdWJtaXQgYW4gYXBwcm9wcmlhdGUgYWx0ZXJuYXRlIHN1YnRhZwogICBhcyBkZXNjcmli ZWQgaW4gdGhhdCBzZWN0aW9uLiAgV2hlbiBlaXRoZXIgYSBjaGFuZ2Ugb3IgYWRkaXRpb24g dG8KICAgdGhlIHJlZ2lzdHJ5IGlzIG5lZWRlZCwgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZp ZXdlciBNVVNUIHByZXBhcmUgdGhlCiAgIGNvbXBsZXRlIHJlY29yZCwgaW5jbHVkaW5nIGFs bCBmaWVsZHMsIGFuZCBmb3J3YXJkIGl0IHRvIElBTkEgZm9yCiAgIGluc2VydGlvbiBpbnRv IHRoZSByZWdpc3RyeS4gIEVhY2ggcmVjb3JkIGJlaW5nIG1vZGlmaWVkIG9yIGluc2VydGVk CiAgIE1VU1QgYmUgZm9yd2FyZGVkIGluIGEgc2VwYXJhdGUgbWVzc2FnZS4KCiAgIElmIGEg cmVjb3JkIHJlcHJlc2VudHMgYSBuZXcgc3VidGFnIHRoYXQgZG9lcyBub3QgY3VycmVudGx5 IGV4aXN0IGluCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDE1 LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDI0XQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNgoK CiAgIHRoZSByZWdpc3RyeSwgdGhlbiB0aGUgbWVzc2FnZSdzIHN1YmplY3QgbGluZSBNVVNU IGluY2x1ZGUgdGhlIHdvcmQKICAgIklOU0VSVCIuICBJZiB0aGUgcmVjb3JkIHJlcHJlc2Vu dHMgYSBjaGFuZ2UgdG8gYW4gZXhpc3Rpbmcgc3VidGFnLAogICB0aGVuIHRoZSBzdWJqZWN0 IGxpbmUgb2YgdGhlIG1lc3NhZ2UgTVVTVCBpbmNsdWRlIHRoZSB3b3JkICJNT0RJRlkiLgog ICBUaGUgbWVzc2FnZSBNVVNUIGNvbnRhaW4gYm90aCB0aGUgcmVjb3JkIGZvciB0aGUgc3Vi dGFnIGJlaW5nCiAgIGluc2VydGVkIG9yIG1vZGlmaWVkIGFuZCB0aGUgbmV3IEZpbGUtRGF0 ZSByZWNvcmQuICBIZXJlIGlzIGFuCiAgIGV4YW1wbGUgb2Ygd2hhdCB0aGUgYm9keSBvZiB0 aGUgbWVzc2FnZSBtaWdodCBjb250YWluOgoKICAgTEFOR1VBR0UgU1VCVEFHIE1PRElGSUNB VElPTgogICBGaWxlLURhdGU6IDIwMDUtMDEtMDIKICAgJSUKICAgVHlwZTogdmFyaWFudAog ICBTdWJ0YWc6IG5lZGlzCiAgIERlc2NyaXB0aW9uOiBOYXRpc29uZSBkaWFsZWN0CiAgIERl c2NyaXB0aW9uOiBOYWRpemEgZGlhbGVjdAogICBBZGRlZDogMjAwMy0xMC0wOQogICBQcmVm aXg6IHNsCiAgIENvbW1lbnRzOiBUaGlzIGlzIGEgY29tbWVudCBzaG93bgogICAgIGFzIGFu IGV4YW1wbGUuCiAgICUlCgogICBGaWd1cmUgNDogRXhhbXBsZSBvZiBhIExhbmd1YWdlIFN1 YnRhZyBNb2RpZmljYXRpb24gRm9ybQoKICAgV2hlbmV2ZXIgYW4gZW50cnkgaXMgY3JlYXRl ZCBvciBtb2RpZmllZCBpbiB0aGUgcmVnaXN0cnksIHRoZSAnRmlsZS0KICAgRGF0ZScgcmVj b3JkIGF0IHRoZSBzdGFydCBvZiB0aGUgcmVnaXN0cnkgaXMgdXBkYXRlZCB0byByZWZsZWN0 IHRoZQogICBtb3N0IHJlY2VudCBtb2RpZmljYXRpb24gZGF0ZSBpbiB0aGUgW1JGQzMzMzld ICJmdWxsLWRhdGUiIGZvcm1hdC4KCiAgIEJlZm9yZSBmb3J3YXJkaW5nIGEgbmV3IHJlZ2lz dHJhdGlvbiB0byBJQU5BLCB0aGUgTGFuZ3VhZ2UgU3VidGFnCiAgIFJldmlld2VyIE1VU1Qg ZW5zdXJlIHRoYXQgdmFsdWVzIGluIHRoZSAnU3VidGFnJyBmaWVsZCBtYXRjaCBjYXNlCiAg IGFjY29yZGluZyB0byB0aGUgZGVzY3JpcHRpb24gaW4gU2VjdGlvbiAzLjEuCgozLjQuICBT dGFiaWxpdHkgb2YgSUFOQSBSZWdpc3RyeSBFbnRyaWVzCgogICBUaGUgc3RhYmlsaXR5IG9m IGVudHJpZXMgYW5kIHRoZWlyIG1lYW5pbmcgaW4gdGhlIHJlZ2lzdHJ5IGlzCiAgIGNyaXRp Y2FsIHRvIHRoZSBsb25nLXRlcm0gc3RhYmlsaXR5IG9mIGxhbmd1YWdlIHRhZ3MuICBUaGUg cnVsZXMgaW4KICAgdGhpcyBzZWN0aW9uIGd1YXJhbnRlZSB0aGF0IGEgc3BlY2lmaWMgbGFu Z3VhZ2UgdGFnJ3MgbWVhbmluZyBpcwogICBzdGFibGUgb3ZlciB0aW1lIGFuZCB3aWxsIG5v dCBjaGFuZ2UuCgogICBUaGVzZSBydWxlcyBzcGVjaWZpY2FsbHkgZGVhbCB3aXRoIGhvdyBj aGFuZ2VzIHRvIGNvZGVzIChpbmNsdWRpbmcKICAgd2l0aGRyYXdhbCBhbmQgZGVwcmVjYXRp b24gb2YgY29kZXMpIG1haW50YWluZWQgYnkgSVNPIDYzOSwgSVNPCiAgIDE1OTI0LCBJU08g MzE2NiwgYW5kIFVOIE0uNDkgYXJlIHJlZmxlY3RlZCBpbiB0aGUgSUFOQSBMYW5ndWFnZQog ICBTdWJ0YWcgUmVnaXN0cnkuICBBc3NpZ25tZW50cyB0byB0aGUgSUFOQSBMYW5ndWFnZSBT dWJ0YWcgUmVnaXN0cnkKICAgTVVTVCBmb2xsb3cgdGhlIGZvbGxvd2luZyBzdGFiaWxpdHkg cnVsZXM6CgogICAxLiAgIFZhbHVlcyBpbiB0aGUgZmllbGRzICdUeXBlJywgJ1N1YnRhZycs ICdUYWcnLCAnQWRkZWQnLAogICAgICAgICdEZXByZWNhdGVkJyBhbmQgJ1ByZWZlcnJlZC1W YWx1ZScgTVVTVCBOT1QgYmUgY2hhbmdlZCBhbmQgYXJlCiAgICAgICAgZ3VhcmFudGVlZCB0 byBiZSBzdGFibGUgb3ZlciB0aW1lLgoKCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBF eHBpcmVzIE1hcmNoIDE1LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDI1XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICBT ZXB0ZW1iZXIgMjAwNgoKCiAgIDIuICAgVmFsdWVzIGluIHRoZSAnRGVzY3JpcHRpb24nIGZp ZWxkIE1VU1QgTk9UIGJlIGNoYW5nZWQgaW4gYSB3YXkKICAgICAgICB0aGF0IHdvdWxkIGlu dmFsaWRhdGUgcHJldmlvdXNseS1leGlzdGluZyB0YWdzLiAgVGhleSBNQVkgYmUKICAgICAg ICBicm9hZGVuZWQgc29tZXdoYXQgaW4gc2NvcGUsIGNoYW5nZWQgdG8gYWRkIGluZm9ybWF0 aW9uLCBvcgogICAgICAgIGFkYXB0ZWQgdG8gdGhlIG1vc3QgY29tbW9uIG1vZGVybiB1c2Fn ZS4gIEZvciBleGFtcGxlLCBjb3VudHJpZXMKICAgICAgICBvY2Nhc2lvbmFsbHkgY2hhbmdl IHRoZWlyIG9mZmljaWFsIG5hbWVzOyBhIGhpc3RvcmljYWwgZXhhbXBsZQogICAgICAgIG9m IHRoaXMgd291bGQgYmUgIlVwcGVyIFZvbHRhIiBjaGFuZ2luZyB0byAiQnVya2luYSBGYXNv Ii4KCiAgIDMuICAgVmFsdWVzIGluIHRoZSBmaWVsZCAnUHJlZml4JyBNQVkgYmUgYWRkZWQg dG8gcmVjb3JkcyBvZiB0eXBlCiAgICAgICAgJ3ZhcmlhbnQnIHZpYSB0aGUgcmVnaXN0cmF0 aW9uIHByb2Nlc3MuICBJZiBhIHByZWZpeCBpcyBhZGRlZCB0bwogICAgICAgIGEgcmVjb3Jk IHRoYXQgZG9lcyBub3QgY29udGFpbiB0aGUgc2FtZSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRh ZwogICAgICAgIGFzIGFuIGV4aXN0aW5nIHByZWZpeCwgb25lICdDb21tZW50JyBmaWVsZCBw ZXIgcHJlZml4IFNIT1VMRCBiZQogICAgICAgIGFkZGVkIHRvIHJlY29yZCBleHBsYWluaW5n IHRoZSBkaWZmZXJlbnQgdXNhZ2VzLgoKICAgNC4gICBWYWx1ZXMgaW4gdGhlIGZpZWxkICdQ cmVmaXgnIGluIHJlY29yZHMgb2YgdHlwZSAndmFyaWFudCcgTUFZIGJlCiAgICAgICAgbW9k aWZpZWQsIHNvIGxvbmcgYXMgdGhlIG1vZGlmaWNhdGlvbnMgYnJvYWRlbiB0aGUgc2V0IG9m CiAgICAgICAgcHJlZml4ZXMuICBUaGF0IGlzLCBhIHByZWZpeCBNQVkgYmUgcmVwbGFjZWQg Ynkgb25lIG9mIGl0cyBvd24KICAgICAgICBwcmVmaXhlcy4gIEZvciBleGFtcGxlLCB0aGUg cHJlZml4ICJlbi1VUyIgY291bGQgYmUgcmVwbGFjZWQgYnkKICAgICAgICAiZW4iLCBidXQg bm90IGJ5IHRoZSBwcmVmaXhlcyAiZW4tTGF0biIsICJmciIsIG9yICJlbi1VUy1ib29udCIu CiAgICAgICAgSWYgb25lIG9mIHRob3NlIHByZWZpeGVzIHdlcmUgbmVlZGVkLCBhIG5ldyBQ cmVmaXggU0hPVUxEIGJlCiAgICAgICAgcmVnaXN0ZXJlZC4KCiAgIDUuICAgVmFsdWVzIGlu IHRoZSBmaWVsZCAnUHJlZml4JyBpbiByZWNvcmRzIG9mIHR5cGUgJ2V4dGxhbmcnIE1VU1QK ICAgICAgICBOT1QgYmUgbW9kaWZpZWQuCgogICA2LiAgIFZhbHVlcyBpbiB0aGUgZmllbGQg J1ByZWZpeCcgTVVTVCBOT1QgYmUgcmVtb3ZlZC4KCiAgIDcuICAgVGhlIGZpZWxkICdDb21t ZW50cycgTUFZIGJlIGFkZGVkLCBjaGFuZ2VkLCBtb2RpZmllZCwgb3IgcmVtb3ZlZAogICAg ICAgIHZpYSB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3Mgb3IgYW55IG9mIHRoZSBwcm9jZXNz ZXMgb3IKICAgICAgICBjb25zaWRlcmF0aW9ucyBkZXNjcmliZWQgaW4gdGhpcyBzZWN0aW9u LgoKICAgOC4gICBUaGUgZmllbGQgJ1N1cHByZXNzLVNjcmlwdCcgTUFZIGJlIGFkZGVkIG9y IHJlbW92ZWQgdmlhIHRoZQogICAgICAgIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLgoKICAgOS4g ICBDb2RlcyBhc3NpZ25lZCBieSBJU08gNjM5LTEgdGhhdCBkbyBub3QgY29uZmxpY3Qgd2l0 aCBleGlzdGluZwogICAgICAgIHR3by1sZXR0ZXIgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdz IGFuZCB3aGljaCBoYXZlIG5vCiAgICAgICAgY29ycmVzcG9uZGluZyB0aHJlZS1sZXR0ZXIg cHJpbWFyeSBvciBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzCiAgICAgICAgZGVmaW5lZCBp biB0aGUgcmVnaXN0cnkgYXJlIGVudGVyZWQgaW50byB0aGUgSUFOQSByZWdpc3RyeSBhcwog ICAgICAgIG5ldyByZWNvcmRzIG9mIHR5cGUgJ2xhbmd1YWdlJy4KCiAgIDEwLiAgQ29kZXMg YXNzaWduZWQgYnkgSVNPIDYzOS0yIHRoYXQgZG8gbm90IGNvbmZsaWN0IHdpdGggZXhpc3Rp bmcKICAgICAgICB0aHJlZS1sZXR0ZXIgcHJpbWFyeSBvciBleHRlbmRlZCBsYW5ndWFnZSBz dWJ0YWdzIGFyZSBlbnRlcmVkCiAgICAgICAgaW50byB0aGUgSUFOQSByZWdpc3RyeSBhcyBu ZXcgcmVjb3JkcyBvZiB0eXBlICdsYW5ndWFnZScuCgogICAxMS4gIENvZGVzIGFzc2lnbmVk IGJ5IElTTyA2MzktMyB0aGF0IGRvIG5vdCBjb25mbGljdCB3aXRoIGV4aXN0aW5nCiAgICAg ICAgdGhyZWUtbGV0dGVyIHByaW1hcnkgb3IgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBh cmUgZW50ZXJlZAogICAgICAgIGludG8gdGhlIElBTkEgcmVnaXN0cnkgYXMgbmV3IHJlY29y ZHMuCgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMTUsIDIw MDcgICAgICAgICAgICAgICAgW1BhZ2UgMjZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA2CgoKICAg ICAgICAxLiAgQ29kZXMgdGhhdCBoYXZlIGEgZGVmaW5lZCAibWFjcm8tbGFuZ3VhZ2UiIG1h cHBpbmcgYXQgdGhlCiAgICAgICAgICAgIHRpbWUgb2YgdGhlaXIgcmVnaXN0cmF0aW9uIE1V U1QgYmUgZW50ZXJlZCBpbnRvIHRoZSByZWdpc3RyeQogICAgICAgICAgICBhcyByZWNvcmRz IG9mIHR5cGUgJ2V4dGxhbmcnIHdpdGggYSAnUHJlZml4JyBmaWVsZAogICAgICAgICAgICBj b250YWluaW5nIHRoZSBhcHByb3ByaWF0ZSBwcmVmaXggdGFnLgoKICAgICAgICAyLiAgQ29k ZXMgdGhhdCByZXByZXNlbnQgc2lnbiBsYW5ndWFnZXMgTVVTVCBiZSBlbnRlcmVkIGludG8g dGhlCiAgICAgICAgICAgIHJlZ2lzdHJ5IGFzIHJlY29yZCBvZiB0eXBlICdleHRsYW5nJyB3 aXRoIGEgJ1ByZWZpeCcgZmllbGQKICAgICAgICAgICAgdGhhdCBtYXRjaGVzIHRoZSBCYXNp YyBMYW5ndWFnZSBSYW5nZSAic2duIiAoc2VlIFNlY3Rpb24KICAgICAgICAgICAgMy4zLjEg IkJhc2ljIEZpbHRlcmluZyIgaW4gW1JGQzQ2NDddKS4KCiAgICAgICAgMy4gIEFsbCBvdGhl ciBjb2RlcyBNVVNUIGJlIGVudGVyZWQgaW50byB0aGUgcmVnaXN0cnkgYXMgcmVjb3Jkcwog ICAgICAgICAgICBvZiB0eXBlICdsYW5ndWFnZScuCgogICAxMi4gIEEgcmVjb3JkIG9mIHR5 cGUgJ2xhbmd1YWdlJyBvciAnZXh0bGFuZycgTVVTVCBOT1QgYmUgcmVnaXN0ZXJlZAogICAg ICAgIGlmIHRoZXJlIGV4aXN0cyBhIHJlY29yZCBvZiBlaXRoZXIgdHlwZSB3aXRoIHRoZSBz YW1lIHN1YnRhZwogICAgICAgIHZhbHVlLiAgRm9yIGV4YW1wbGUsIGlmIGFuICdleHRsYW5n JyBzdWJ0YWcgJ2ZvbycgZXhpc3RzLCBhbGwKICAgICAgICBhdHRlbXB0cyB0byByZWdpc3Rl ciBhICdsYW5ndWFnZScgc3VidGFnICdmb28nIHdpbGwgYmUgcmVqZWN0ZWQuCgogICAxMy4g IENvZGVzIGFzc2lnbmVkIGJ5IElTTyAxNTkyNCBhbmQgSVNPIDMxNjYgdGhhdCBkbyBub3Qg Y29uZmxpY3QKICAgICAgICB3aXRoIGV4aXN0aW5nIHN1YnRhZ3Mgb2YgdGhlIGFzc29jaWF0 ZWQgdHlwZSBhbmQgd2hvc2UgbWVhbmluZwogICAgICAgIGlzIG5vdCB0aGUgc2FtZSBhcyBh biBleGlzdGluZyBzdWJ0YWcgb2YgdGhlIHNhbWUgdHlwZSBhcmUKICAgICAgICBlbnRlcmVk IGludG8gdGhlIElBTkEgcmVnaXN0cnkgYXMgbmV3IHJlY29yZHMuCgogICAxNC4gIENvZGVz IGFzc2lnbmVkIGJ5IElTTyA2MzksIElTTyAxNTkyNCwgb3IgSVNPIDMxNjYgdGhhdCBhcmUK ICAgICAgICB3aXRoZHJhd24gYnkgdGhlaXIgcmVzcGVjdGl2ZSBtYWludGVuYW5jZSBvciBy ZWdpc3RyYXRpb24KICAgICAgICBhdXRob3JpdHkgcmVtYWluIHZhbGlkIGluIGxhbmd1YWdl IHRhZ3MuICBBICdEZXByZWNhdGVkJyBmaWVsZAogICAgICAgIGNvbnRhaW5pbmcgdGhlIGRh dGUgb2Ygd2l0aGRyYXdhbCBNVVNUIGJlIGFkZGVkIHRvIHRoZSByZWNvcmQuCiAgICAgICAg SWYgYSBuZXcgcmVjb3JkIG9mIHRoZSBzYW1lIHR5cGUgaXMgYWRkZWQgdGhhdCByZXByZXNl bnRzIGEKICAgICAgICByZXBsYWNlbWVudCB2YWx1ZSwgdGhlbiBhICdQcmVmZXJyZWQtVmFs dWUnIGZpZWxkIE1BWSBhbHNvIGJlCiAgICAgICAgYWRkZWQuICBUaGUgcmVnaXN0cmF0aW9u IHByb2Nlc3MgTUFZIGJlIHVzZWQgdG8gYWRkIGNvbW1lbnRzCiAgICAgICAgYWJvdXQgdGhl IHdpdGhkcmF3YWwgb2YgdGhlIGNvZGUgYnkgdGhlIHJlc3BlY3RpdmUgc3RhbmRhcmQuCgog ICAgICAgIEV4YW1wbGUgVGhlIHJlZ2lvbiBjb2RlICdUTCcgd2FzIGFzc2lnbmVkIHRvIHRo ZSBjb3VudHJ5ICdUaW1vci0KICAgICAgICAgICBMZXN0ZScsIHJlcGxhY2luZyB0aGUgY29k ZSAnVFAnICh3aGljaCB3YXMgYXNzaWduZWQgdG8gJ0Vhc3QKICAgICAgICAgICBUaW1vcicg d2hlbiBpdCB3YXMgdW5kZXIgYWRtaW5pc3RyYXRpb24gYnkgUG9ydHVnYWwpLiAgVGhlCiAg ICAgICAgICAgc3VidGFnICdUUCcgcmVtYWlucyB2YWxpZCBpbiBsYW5ndWFnZSB0YWdzLCBi dXQgaXRzIHJlY29yZAogICAgICAgICAgIGNvbnRhaW5zIHRoZSBhICdQcmVmZXJyZWQtVmFs dWUnIG9mICdUTCcgYW5kIGl0cyBmaWVsZAogICAgICAgICAgICdEZXByZWNhdGVkJyBjb250 YWlucyB0aGUgZGF0ZSB0aGUgbmV3IGNvZGUgd2FzIGFzc2lnbmVkCiAgICAgICAgICAgKCcy MDA0LTA3LTA2JykuCgogICAxNS4gIENvZGVzIGFzc2lnbmVkIGJ5IElTTyA2MzksIElTTyAx NTkyNCwgb3IgSVNPIDMxNjYgdGhhdCBjb25mbGljdAogICAgICAgIHdpdGggZXhpc3Rpbmcg c3VidGFncyBvZiB0aGUgYXNzb2NpYXRlZCB0eXBlLCBpbmNsdWRpbmcgc3VidGFncwogICAg ICAgIHRoYXQgYXJlIGRlcHJlY2F0ZWQsIE1VU1QgTk9UIGJlIGVudGVyZWQgaW50byB0aGUg cmVnaXN0cnkuICBUaGUKICAgICAgICBmb2xsb3dpbmcgYWRkaXRpb25hbCBjb25zaWRlcmF0 aW9ucyBhcHBseSB0byBzdWJ0YWcgdmFsdWVzIHRoYXQKICAgICAgICBhcmUgcmVhc3NpZ25l ZDoKCiAgICAgICAgQS4gIEZvciBJU08gNjM5IGNvZGVzLCBpZiB0aGUgbmV3bHkgYXNzaWdu ZWQgY29kZSdzIG1lYW5pbmcgaXMKICAgICAgICAgICAgbm90IHJlcHJlc2VudGVkIGJ5IGEg c3VidGFnIGluIHRoZSBJQU5BIHJlZ2lzdHJ5LCB0aGUKCgoKUGhpbGxpcHMgJiBEYXZpcyAg ICAgICAgIEV4cGlyZXMgTWFyY2ggMTUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMjdd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgIFNlcHRlbWJlciAyMDA2CgoKICAgICAgICAgICAgTGFuZ3VhZ2UgU3VidGFnIFJl dmlld2VyLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjUsIFNIQUxMCiAgICAgICAgICAg IHByZXBhcmUgYSBwcm9wb3NhbCBmb3IgZW50ZXJpbmcgaW4gdGhlIElBTkEgcmVnaXN0cnkg YXMgc29vbgogICAgICAgICAgICBhcyBwcmFjdGljYWwgYSByZWdpc3RlcmVkIGxhbmd1YWdl IHN1YnRhZyBhcyBhbiBhbHRlcm5hdGUKICAgICAgICAgICAgdmFsdWUgZm9yIHRoZSBuZXcg Y29kZS4gIFRoZSBmb3JtIG9mIHRoZSByZWdpc3RlcmVkIGxhbmd1YWdlCiAgICAgICAgICAg IHN1YnRhZyB3aWxsIGJlIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBMYW5ndWFnZSBTdWJ0 YWcKICAgICAgICAgICAgUmV2aWV3ZXIgYW5kIE1VU1QgY29uZm9ybSB0byBvdGhlciByZXN0 cmljdGlvbnMgb24gbGFuZ3VhZ2UKICAgICAgICAgICAgc3VidGFncyBpbiB0aGlzIGRvY3Vt ZW50LgoKICAgICAgICBCLiAgRm9yIGFsbCBzdWJ0YWdzIHdob3NlIG1lYW5pbmcgaXMgZGVy aXZlZCBmcm9tIGFuIGV4dGVybmFsCiAgICAgICAgICAgIHN0YW5kYXJkICh0aGF0IGlzLCBi eSBJU08gNjM5LCBJU08gMTU5MjQsIElTTyAzMTY2LCBvciBVTgogICAgICAgICAgICBNLjQ5 KSwgaWYgYSBuZXcgbWVhbmluZyBpcyBhc3NpZ25lZCB0byBhbiBleGlzdGluZyBjb2RlIGFu ZAogICAgICAgICAgICB0aGUgbmV3IG1lYW5pbmcgYnJvYWRlbnMgdGhlIG1lYW5pbmcgb2Yg dGhhdCBjb2RlLCB0aGVuIHRoZQogICAgICAgICAgICBtZWFuaW5nIGZvciB0aGUgYXNzb2Np YXRlZCBzdWJ0YWcgTUFZIGJlIGNoYW5nZWQgdG8gbWF0Y2guCiAgICAgICAgICAgIFRoZSBt ZWFuaW5nIG9mIGEgc3VidGFnIE1VU1QgTk9UIGJlIG5hcnJvd2VkLCBob3dldmVyLCBhcwog ICAgICAgICAgICB0aGlzIGNhbiByZXN1bHQgaW4gYW4gdW5rbm93biBwcm9wb3J0aW9uIG9m IHRoZSBleGlzdGluZwogICAgICAgICAgICB1c2VzIG9mIGEgc3VidGFnIGJlY29taW5nIGlu dmFsaWQuICBOb3RlOiBJU08gNjM5CiAgICAgICAgICAgIG1haW50ZW5hbmNlIGFnZW5jeS9y ZWdpc3RyYXRpb24gYXV0aG9yaXR5IChNQS9SQSkgaGFzCiAgICAgICAgICAgIGFkb3B0ZWQg YSBzaW1pbGFyIHN0YWJpbGl0eSBwb2xpY3kuCgogICAgICAgIEMuICBGb3IgSVNPIDE1OTI0 IGNvZGVzLCBpZiB0aGUgbmV3bHkgYXNzaWduZWQgY29kZSdzIG1lYW5pbmcgaXMKICAgICAg ICAgICAgbm90IHJlcHJlc2VudGVkIGJ5IGEgc3VidGFnIGluIHRoZSBJQU5BIHJlZ2lzdHJ5 LCB0aGUKICAgICAgICAgICAgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyLCBhcyBkZXNjcmli ZWQgaW4gU2VjdGlvbiAzLjUsIFNIQUxMCiAgICAgICAgICAgIHByZXBhcmUgYSBwcm9wb3Nh bCBmb3IgZW50ZXJpbmcgaW4gdGhlIElBTkEgcmVnaXN0cnkgYXMgc29vbgogICAgICAgICAg ICBhcyBwcmFjdGljYWwgYSByZWdpc3RlcmVkIHZhcmlhbnQgc3VidGFnIGFzIGFuIGFsdGVy bmF0ZQogICAgICAgICAgICB2YWx1ZSBmb3IgdGhlIG5ldyBjb2RlLiAgVGhlIGZvcm0gb2Yg dGhlIHJlZ2lzdGVyZWQgdmFyaWFudAogICAgICAgICAgICBzdWJ0YWcgd2lsbCBiZSBhdCB0 aGUgZGlzY3JldGlvbiBvZiB0aGUgTGFuZ3VhZ2UgU3VidGFnCiAgICAgICAgICAgIFJldmll d2VyIGFuZCBNVVNUIGNvbmZvcm0gdG8gb3RoZXIgcmVzdHJpY3Rpb25zIG9uIHZhcmlhbnQK ICAgICAgICAgICAgc3VidGFncyBpbiB0aGlzIGRvY3VtZW50LgoKICAgICAgICBELiAgRm9y IElTTyAzMTY2IGNvZGVzLCBpZiB0aGUgbmV3bHkgYXNzaWduZWQgY29kZSdzIG1lYW5pbmcg aXMKICAgICAgICAgICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBzYW1lIFVOIE0uNDkgY29kZSBh cyBhbm90aGVyICdyZWdpb24nCiAgICAgICAgICAgIHN1YnRhZywgdGhlbiB0aGUgZXhpc3Rp bmcgcmVnaW9uIHN1YnRhZyByZW1haW5zIGFzIHRoZQogICAgICAgICAgICBwcmVmZXJyZWQg dmFsdWUgZm9yIHRoYXQgcmVnaW9uIGFuZCBubyBuZXcgZW50cnkgaXMgY3JlYXRlZC4KICAg ICAgICAgICAgQSBjb21tZW50IE1BWSBiZSBhZGRlZCB0byB0aGUgZXhpc3RpbmcgcmVnaW9u IHN1YnRhZwogICAgICAgICAgICBpbmRpY2F0aW5nIHRoZSByZWxhdGlvbnNoaXAgdG8gdGhl IG5ldyBJU08gMzE2NiBjb2RlLgoKICAgICAgICBFLiAgRm9yIElTTyAzMTY2IGNvZGVzLCBp ZiB0aGUgbmV3bHkgYXNzaWduZWQgY29kZSdzIG1lYW5pbmcgaXMKICAgICAgICAgICAgYXNz b2NpYXRlZCB3aXRoIGEgVU4gTS40OSBjb2RlIHRoYXQgaXMgbm90IHJlcHJlc2VudGVkIGJ5 IGFuCiAgICAgICAgICAgIGV4aXN0aW5nIHJlZ2lvbiBzdWJ0YWcsIHRoZW4gdGhlIExhbmd1 YWdlIFN1YnRhZyBSZXZpZXdlciwKICAgICAgICAgICAgYXMgZGVzY3JpYmVkIGluIFNlY3Rp b24gMy41LCBTSEFMTCBwcmVwYXJlIGEgcHJvcG9zYWwgZm9yCiAgICAgICAgICAgIGVudGVy aW5nIHRoZSBhcHByb3ByaWF0ZSBVTiBNLjQ5IGNvdW50cnkgY29kZSBhcyBhbiBlbnRyeSBp bgogICAgICAgICAgICB0aGUgSUFOQSByZWdpc3RyeS4KCiAgICAgICAgRi4gIEZvciBJU08g MzE2NiBjb2RlcywgaWYgdGhlcmUgaXMgbm8gYXNzb2NpYXRlZCBVTiBudW1lcmljCiAgICAg ICAgICAgIGNvZGUsIHRoZW4gdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBTSEFMTCBw ZXRpdGlvbiB0aGUKICAgICAgICAgICAgVU4gdG8gY3JlYXRlIG9uZS4gIElmIHRoZXJlIGlz IG5vIHJlc3BvbnNlIGZyb20gdGhlIFVOCiAgICAgICAgICAgIHdpdGhpbiBuaW5ldHkgZGF5 cyBvZiB0aGUgcmVxdWVzdCBiZWluZyBzZW50LCB0aGUgTGFuZ3VhZ2UKICAgICAgICAgICAg U3VidGFnIFJldmlld2VyIFNIQUxMIHByZXBhcmUgYSBwcm9wb3NhbCBmb3IgZW50ZXJpbmcg aW4gdGhlCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDE1LCAy MDA3ICAgICAgICAgICAgICAgIFtQYWdlIDI4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNgoKCiAg ICAgICAgICAgIElBTkEgcmVnaXN0cnkgYXMgc29vbiBhcyBwcmFjdGljYWwgYSByZWdpc3Rl cmVkIHZhcmlhbnQKICAgICAgICAgICAgc3VidGFnIGFzIGFuIGFsdGVybmF0ZSB2YWx1ZSBm b3IgdGhlIG5ldyBjb2RlLiAgVGhlIGZvcm0gb2YKICAgICAgICAgICAgdGhlIHJlZ2lzdGVy ZWQgdmFyaWFudCBzdWJ0YWcgd2lsbCBiZSBhdCB0aGUgZGlzY3JldGlvbiBvZgogICAgICAg ICAgICB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIGFuZCBNVVNUIGNvbmZvcm0gdG8g b3RoZXIKICAgICAgICAgICAgcmVzdHJpY3Rpb25zIG9uIHZhcmlhbnQgc3VidGFncyBpbiB0 aGlzIGRvY3VtZW50LiAgVGhpcwogICAgICAgICAgICBzaXR1YXRpb24gaXMgdmVyeSB1bmxp a2VseSB0byBldmVyIG9jY3VyLgoKICAgMTYuICBVTiBNLjQ5IGhhcyBjb2RlcyBmb3IgYm90 aCBjb3VudHJpZXMgYW5kIGFyZWFzIChzdWNoIGFzICcyNzYnCiAgICAgICAgZm9yIEdlcm1h bnkpIGFuZCBnZW9ncmFwaGljYWwgcmVnaW9ucyBhbmQgc3ViLXJlZ2lvbnMgKHN1Y2ggYXMK ICAgICAgICAnMTUwJyBmb3IgRXVyb3BlKS4gIFVOIE0uNDkgY291bnRyeSBvciBhcmVhIGNv ZGVzIGZvciB3aGljaAogICAgICAgIHRoZXJlIGlzIG5vIGNvcnJlc3BvbmRpbmcgSVNPIDMx NjYgY29kZSBTSE9VTEQgTk9UIGJlCiAgICAgICAgcmVnaXN0ZXJlZCwgZXhjZXB0IGFzIGEg c3Vycm9nYXRlIGZvciBhbiBJU08gMzE2NiBjb2RlIHRoYXQgaXMKICAgICAgICBibG9ja2Vk IGZyb20gcmVnaXN0cmF0aW9uIGJ5IGFuIGV4aXN0aW5nIHN1YnRhZy4gIElmIHN1Y2ggYSBj b2RlCiAgICAgICAgYmVjb21lcyBuZWNlc3NhcnksIHRoZW4gdGhlIHJlZ2lzdHJhdGlvbiBh dXRob3JpdHkgZm9yIElTTyAzMTY2CiAgICAgICAgU0hPVUxEIGZpcnN0IGJlIHBldGl0aW9u ZWQgdG8gYXNzaWduIGEgY29kZSB0byB0aGUgcmVnaW9uLiAgSWYKICAgICAgICB0aGUgcGV0 aXRpb24gZm9yIGEgY29kZSBhc3NpZ25tZW50IGJ5IElTTyAzMTY2IGlzIHJlZnVzZWQgb3Ig bm90CiAgICAgICAgYWN0ZWQgb24gaW4gYSB0aW1lbHkgbWFubmVyLCB0aGUgcmVnaXN0cmF0 aW9uIHByb2Nlc3MgZGVzY3JpYmVkCiAgICAgICAgaW4gU2VjdGlvbiAzLjUgTUFZIHRoZW4g YmUgdXNlZCB0byByZWdpc3RlciB0aGUgY29ycmVzcG9uZGluZyBVTgogICAgICAgIE0uNDkg Y29kZS4gIFRoaXMgd2F5LCBVTiBNLjQ5IGNvZGVzIHJlbWFpbiBhdmFpbGFibGUgYXMgdGhl CiAgICAgICAgdmFsdWUgb2YgbGFzdCByZXNvcnQgaW4gY2FzZXMgd2hlcmUgSVNPIDMxNjYg cmVhc3NpZ25zIGEKICAgICAgICBkZXByZWNhdGVkIHZhbHVlIGluIHRoZSByZWdpc3RyeS4K CiAgIDE3LiAgU3RhYmlsaXR5IHByb3Zpc2lvbnMgYXBwbHkgdG8gZ3JhbmRmYXRoZXJlZCB0 YWdzIHdpdGggdGhpcwogICAgICAgIGV4Y2VwdGlvbjogc2hvdWxkIGFsbCBvZiB0aGUgc3Vi dGFncyBpbiBhIGdyYW5kZmF0aGVyZWQgdGFnCiAgICAgICAgYmVjb21lIHZhbGlkIHN1YnRh Z3MgaW4gdGhlIElBTkEgcmVnaXN0cnksIHRoZW4gdGhlIGZpZWxkICdUeXBlJwogICAgICAg IGluIHRoYXQgcmVjb3JkIGlzIGNoYW5nZWQgZnJvbSAnZ3JhbmRmYXRoZXJlZCcgdG8gJ3Jl ZHVuZGFudCcuCiAgICAgICAgTm90ZSB0aGF0IHRoaXMgd2lsbCBub3QgYWZmZWN0IGxhbmd1 YWdlIHRhZ3MgdGhhdCBtYXRjaCB0aGUKICAgICAgICBncmFuZGZhdGhlcmVkIHRhZywgc2lu Y2UgdGhlc2UgdGFncyB3aWxsIG5vdyBtYXRjaCB2YWxpZAogICAgICAgIGdlbmVyYXRpdmUg c3VidGFnIHNlcXVlbmNlcy4gIEZvciBleGFtcGxlLCBpZiB0aGUgc3VidGFnICdnYW4nCiAg ICAgICAgaW4gdGhlIGxhbmd1YWdlIHRhZyAiemgtZ2FuIiB3ZXJlIHRvIGJlIHJlZ2lzdGVy ZWQgYXMgYW4KICAgICAgICBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcsIHRoZW4gdGhlIGdy YW5kZmF0aGVyZWQgdGFnICJ6aC1nYW4iCiAgICAgICAgd291bGQgYmUgZGVwcmVjYXRlZCAo YnV0IGV4aXN0aW5nIGNvbnRlbnQgb3IgaW1wbGVtZW50YXRpb25zCiAgICAgICAgdGhhdCB1 c2UgInpoLWdhbiIgd291bGQgcmVtYWluIHZhbGlkKS4KCjMuNS4gIFJlZ2lzdHJhdGlvbiBQ cm9jZWR1cmUgZm9yIFN1YnRhZ3MKCiAgIFRoZSBwcm9jZWR1cmUgZ2l2ZW4gaGVyZSBNVVNU IGJlIHVzZWQgYnkgYW55b25lIHdobyB3YW50cyB0byB1c2UgYQogICBzdWJ0YWcgbm90IGN1 cnJlbnRseSBpbiB0aGUgSUFOQSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkuCgogICBPbmx5 IHN1YnRhZ3Mgb2YgdHlwZSAnbGFuZ3VhZ2UnIGFuZCAndmFyaWFudCcgd2lsbCBiZSBjb25z aWRlcmVkIGZvcgogICBpbmRlcGVuZGVudCByZWdpc3RyYXRpb24gb2YgbmV3IHN1YnRhZ3Mu ICBIYW5kbGluZyBvZiBzdWJ0YWdzIG5lZWRlZAogICBmb3Igc3RhYmlsaXR5IGFuZCBzdWJ0 YWdzIG5lY2Vzc2FyeSB0byBrZWVwIHRoZSByZWdpc3RyeSBzeW5jaHJvbml6ZWQKICAgd2l0 aCBJU08gNjM5LCBJU08gMTU5MjQsIElTTyAzMTY2LCBhbmQgVU4gTS40OSB3aXRoaW4gdGhl IGxpbWl0cwogICBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQgYXJlIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDMuMy4gIFN0YWJpbGl0eQogICBwcm92aXNpb25zIGFyZSBkZXNjcmliZWQgaW4g U2VjdGlvbiAzLjQuCgogICBUaGlzIHByb2NlZHVyZSBNQVkgYWxzbyBiZSB1c2VkIHRvIHJl Z2lzdGVyIG9yIGFsdGVyIHRoZSBpbmZvcm1hdGlvbgogICBmb3IgdGhlICdEZXNjcmlwdGlv bicsICdDb21tZW50cycsICdEZXByZWNhdGVkJywgb3IgJ1ByZWZpeCcgZmllbGRzCgoKClBo aWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDE1LCAyMDA3ICAgICAgICAg ICAgICAgIFtQYWdlIDI5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFn cy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNgoKCiAgIGluIGEgc3VidGFn J3MgcmVjb3JkIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNC4gIENoYW5nZXMgdG8gYWxs CiAgIG90aGVyIGZpZWxkcyBpbiB0aGUgSUFOQSByZWdpc3RyeSBhcmUgTk9UIHBlcm1pdHRl ZC4KCiAgIFJlZ2lzdGVyaW5nIGEgbmV3IHN1YnRhZyBvciByZXF1ZXN0aW5nIG1vZGlmaWNh dGlvbnMgdG8gYW4gZXhpc3RpbmcKICAgdGFnIG9yIHN1YnRhZyBzdGFydHMgd2l0aCB0aGUg cmVxdWVzdGVyIGZpbGxpbmcgb3V0IHRoZSByZWdpc3RyYXRpb24KICAgZm9ybSByZXByb2R1 Y2VkIGJlbG93LiAgTm90ZSB0aGF0IGVhY2ggcmVzcG9uc2UgaXMgbm90IGxpbWl0ZWQgaW4K ICAgc2l6ZSBzbyB0aGF0IHRoZSByZXF1ZXN0IGNhbiBhZGVxdWF0ZWx5IGRlc2NyaWJlIHRo ZSByZWdpc3RyYXRpb24uCiAgIFRoZSBmaWVsZHMgaW4gdGhlICJSZWNvcmQgUmVxdWVzdGVk IiBzZWN0aW9uIFNIT1VMRCBmb2xsb3cgdGhlCiAgIHJlcXVpcmVtZW50cyBpbiBTZWN0aW9u IDMuMS4KCiAgIExBTkdVQUdFIFNVQlRBRyBSRUdJU1RSQVRJT04gRk9STQogICAxLiBOYW1l IG9mIHJlcXVlc3RlcjoKICAgMi4gRS1tYWlsIGFkZHJlc3Mgb2YgcmVxdWVzdGVyOgogICAz LiBSZWNvcmQgUmVxdWVzdGVkOgoKICAgICAgVHlwZToKICAgICAgU3VidGFnOgogICAgICBE ZXNjcmlwdGlvbjoKICAgICAgUHJlZml4OgogICAgICBQcmVmZXJyZWQtVmFsdWU6CiAgICAg IERlcHJlY2F0ZWQ6CiAgICAgIFN1cHByZXNzLVNjcmlwdDoKICAgICAgQ29tbWVudHM6Cgog ICA0LiBJbnRlbmRlZCBtZWFuaW5nIG9mIHRoZSBzdWJ0YWc6CiAgIDUuIFJlZmVyZW5jZSB0 byBwdWJsaXNoZWQgZGVzY3JpcHRpb24KICAgICAgb2YgdGhlIGxhbmd1YWdlIChib29rIG9y IGFydGljbGUpOgogICA2LiBBbnkgb3RoZXIgcmVsZXZhbnQgaW5mb3JtYXRpb246CgogICBG aWd1cmUgNTogVGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyYXRpb24gRm9ybQoKICAgVGhl IHN1YnRhZyByZWdpc3RyYXRpb24gZm9ybSBNVVNUIGJlIHNlbnQgdG8KICAgPGlldGYtbGFu Z3VhZ2VzQGlhbmEub3JnPiBmb3IgYSB0d28td2VlayByZXZpZXcgcGVyaW9kIGJlZm9yZSBp dCBjYW4KICAgYmUgc3VibWl0dGVkIHRvIElBTkEuICAoVGhpcyBpcyBhbiBvcGVuIGxpc3Qg YW5kIGNhbiBiZSBqb2luZWQgYnkKICAgc2VuZGluZyBhIHJlcXVlc3QgdG8gPGlldGYtbGFu Z3VhZ2VzLXJlcXVlc3RAaWFuYS5vcmc+LikKCiAgIFZhcmlhbnQgc3VidGFncyBhcmUgdXN1 YWxseSByZWdpc3RlcmVkIGZvciB1c2Ugd2l0aCBhIHBhcnRpY3VsYXIKICAgcmFuZ2Ugb2Yg bGFuZ3VhZ2UgdGFncy4gIEZvciBleGFtcGxlLCB0aGUgc3VidGFnICdyb3phaicgaXMgaW50 ZW5kZWQKICAgZm9yIHVzZSB3aXRoIGxhbmd1YWdlIHRhZ3MgdGhhdCBzdGFydCB3aXRoIHRo ZSBwcmltYXJ5IGxhbmd1YWdlCiAgIHN1YnRhZyAic2wiLCBzaW5jZSBSZXNpYW4gaXMgYSBk aWFsZWN0IG9mIFNsb3Zlbmlhbi4gIFRodXMsIHRoZQogICBzdWJ0YWcgJ3JvemFqJyB3b3Vs ZCBiZSBhcHByb3ByaWF0ZSBpbiB0YWdzIHN1Y2ggYXMgInNsLUxhdG4tcm96YWoiCiAgIG9y ICJzbC1JVC1yb3phaiIuICBUaGlzIGluZm9ybWF0aW9uIGlzIHN0b3JlZCBpbiB0aGUgJ1By ZWZpeCcgZmllbGQKICAgaW4gdGhlIHJlZ2lzdHJ5LiAgVmFyaWFudCByZWdpc3RyYXRpb24g cmVxdWVzdHMgU0hPVUxEIGluY2x1ZGUgYXQKICAgbGVhc3Qgb25lICdQcmVmaXgnIGZpZWxk IGluIHRoZSByZWdpc3RyYXRpb24gZm9ybS4KCiAgIEV4dGVuZGVkIGxhbmd1YWdlIHN1YnRh Z3MgYXJlIHJlc2VydmVkIGZvciBmdXR1cmUgc3RhbmRhcmRpemF0aW9uLgogICBUaGVzZSBz dWJ0YWdzIHdpbGwgYmUgUkVRVUlSRUQgdG8gaW5jbHVkZSBleGFjdGx5IG9uZSAnUHJlZml4 JyBmaWVsZAogICBvbmNlIHRoZXkgYXJlIGFsbG93ZWQgZm9yIHJlZ2lzdHJhdGlvbi4KCgoK UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMTUsIDIwMDcgICAgICAg ICAgICAgICAgW1BhZ2UgMzBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0 YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA2CgoKICAgVGhlICdQcmVm aXgnIGZpZWxkIGZvciBhIGdpdmVuIHJlZ2lzdGVyZWQgc3VidGFnIGV4aXN0cyBpbiB0aGUg SUFOQQogICByZWdpc3RyeSBhcyBhIGd1aWRlIHRvIHVzYWdlLiAgQWRkaXRpb25hbCBwcmVm aXhlcyBNQVkgYmUgYWRkZWQgYnkKICAgZmlsaW5nIGFuIGFkZGl0aW9uYWwgcmVnaXN0cmF0 aW9uIGZvcm0uICBJbiB0aGF0IGZvcm0sIHRoZSAiQW55IG90aGVyCiAgIHJlbGV2YW50IGlu Zm9ybWF0aW9uOiIgZmllbGQgTVVTVCBpbmRpY2F0ZSB0aGF0IGl0IGlzIHRoZSBhZGRpdGlv biBvZgogICBhIHByZWZpeC4KCiAgIFJlcXVlc3RzIHRvIGFkZCBhIHByZWZpeCB0byBhIHZh cmlhbnQgc3VidGFnIHRoYXQgaW1wbHkgYSBkaWZmZXJlbnQKICAgc2VtYW50aWMgbWVhbmlu ZyB3aWxsIHByb2JhYmx5IGJlIHJlamVjdGVkLiAgRm9yIGV4YW1wbGUsIGEgcmVxdWVzdAog ICB0byBhZGQgdGhlIHByZWZpeCAiZGUiIHRvIHRoZSBzdWJ0YWcgJ25lZGlzJyBzbyB0aGF0 IHRoZSB0YWcgImRlLQogICBuZWRpcyIgcmVwcmVzZW50ZWQgc29tZSBHZXJtYW4gZGlhbGVj dCB3b3VsZCBiZSByZWplY3RlZC4gIFRoZQogICAnbmVkaXMnIHN1YnRhZyByZXByZXNlbnRz IGEgcGFydGljdWxhciBTbG92ZW5pYW4gZGlhbGVjdCBhbmQgdGhlCiAgIGFkZGl0aW9uYWwg cmVnaXN0cmF0aW9uIHdvdWxkIGNoYW5nZSB0aGUgc2VtYW50aWMgbWVhbmluZyBhc3NpZ25l ZCB0bwogICB0aGUgc3VidGFnLiAgQSBzZXBhcmF0ZSBzdWJ0YWcgU0hPVUxEIGJlIHByb3Bv c2VkIGluc3RlYWQuCgogICBUaGUgJ0Rlc2NyaXB0aW9uJyBmaWVsZCBNVVNUIGNvbnRhaW4g YSBkZXNjcmlwdGlvbiBvZiB0aGUgdGFnIGJlaW5nCiAgIHJlZ2lzdGVyZWQgd3JpdHRlbiBv ciB0cmFuc2NyaWJlZCBpbnRvIHRoZSBMYXRpbiBzY3JpcHQ7IGl0IE1BWSBhbHNvCiAgIGlu Y2x1ZGUgYSBkZXNjcmlwdGlvbiBpbiBhIG5vbi1MYXRpbiBzY3JpcHQuICBOb24tQVNDSUkg Y2hhcmFjdGVycwogICBNVVNUIGJlIGVzY2FwZWQgdXNpbmcgdGhlIHN5bnRheCBkZXNjcmli ZWQgaW4gU2VjdGlvbiAzLjEuICBUaGUKICAgJ0Rlc2NyaXB0aW9uJyBmaWVsZCBpcyB1c2Vk IGZvciBpZGVudGlmaWNhdGlvbiBwdXJwb3NlcyBhbmQgZG9lc24ndAogICBuZWNlc3Nhcmls eSByZXByZXNlbnQgdGhlIGFjdHVhbCBuYXRpdmUgbmFtZSBvZiB0aGUgbGFuZ3VhZ2Ugb3IK ICAgdmFyaWF0aW9uIG9yIHRvIGJlIGluIGFueSBwYXJ0aWN1bGFyIGxhbmd1YWdlLgoKICAg V2hpbGUgdGhlICdEZXNjcmlwdGlvbicgZmllbGQgaXRzZWxmIGlzIG5vdCBndWFyYW50ZWVk IHRvIGJlIHN0YWJsZQogICBhbmQgZXJyYXRhIGNvcnJlY3Rpb25zIE1BWSBiZSB1bmRlcnRh a2VuIGZyb20gdGltZSB0byB0aW1lLCBhdHRlbXB0cwogICB0byBwcm92aWRlIHRyYW5zbGF0 aW9ucyBvciB0cmFuc2NyaXB0aW9ucyBvZiBlbnRyaWVzIGluIHRoZSByZWdpc3RyeQogICBp dHNlbGYgd2lsbCBwcm9iYWJseSBiZSBmcm93bmVkIHVwb24gYnkgdGhlIGNvbW11bml0eSBv ciByZWplY3RlZAogICBvdXRyaWdodCwgYXMgY2hhbmdlcyBvZiB0aGlzIG5hdHVyZSBoYXZl IGFuIGltcGFjdCBvbiB0aGUgcHJvdmlzaW9ucwogICBpbiBTZWN0aW9uIDMuNC4KCiAgIFdo ZW4gdGhlIHR3by13ZWVrIHBlcmlvZCBoYXMgcGFzc2VkLCB0aGUgTGFuZ3VhZ2UgU3VidGFn IFJldmlld2VyCiAgIGVpdGhlciBmb3J3YXJkcyB0aGUgcmVjb3JkIHRvIGJlIGluc2VydGVk IG9yIG1vZGlmaWVkIHRvCiAgIGlhbmFAaWFuYS5vcmcgYWNjb3JkaW5nIHRvIHRoZSBwcm9j ZWR1cmUgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4zLCBvcgogICByZWplY3RzIHRoZSByZXF1 ZXN0IGJlY2F1c2Ugb2Ygc2lnbmlmaWNhbnQgb2JqZWN0aW9ucyByYWlzZWQgb24gdGhlCiAg IGxpc3Qgb3IgZHVlIHRvIHByb2JsZW1zIHdpdGggY29uc3RyYWludHMgaW4gdGhpcyBkb2N1 bWVudCAod2hpY2ggTVVTVAogICBiZSBleHBsaWNpdGx5IGNpdGVkKS4gIFRoZSBMYW5ndWFn ZSBTdWJ0YWcgUmV2aWV3ZXIgTUFZIGFsc28gZXh0ZW5kCiAgIHRoZSByZXZpZXcgcGVyaW9k IGluIHR3by13ZWVrIGluY3JlbWVudHMgdG8gcGVybWl0IGZ1cnRoZXIKICAgZGlzY3Vzc2lv bi4gIFRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgTVVTVCBpbmRpY2F0ZSBvbiB0aGUg bGlzdAogICB3aGV0aGVyIHRoZSByZWdpc3RyYXRpb24gaGFzIGJlZW4gYWNjZXB0ZWQsIHJl amVjdGVkLCBvciBleHRlbmRlZAogICBmb2xsb3dpbmcgZWFjaCB0d28td2VlayBwZXJpb2Qu CgogICBOb3RlIHRoYXQgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBNQVkgcmFpc2Ug b2JqZWN0aW9ucyBvbiB0aGUKICAgbGlzdCBpZiBoZSBvciBzaGUgc28gZGVzaXJlcy4gIFRo ZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhhdCB0aGUKICAgb2JqZWN0aW9uIE1VU1QgYmUgbWFk ZSBwdWJsaWNseS4KCiAgIFRoZSBhcHBsaWNhbnQgaXMgZnJlZSB0byBtb2RpZnkgYSByZWpl Y3RlZCBhcHBsaWNhdGlvbiB3aXRoCiAgIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYW5kIHN1 Ym1pdCBpdCBhZ2FpbjsgdGhpcyByZXN0YXJ0cyB0aGUgdHdvLQogICB3ZWVrIGNvbW1lbnQg cGVyaW9kLgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMTUs IDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMzFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA2CgoK ICAgRGVjaXNpb25zIG1hZGUgYnkgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBNQVkg YmUgYXBwZWFsZWQgdG8gdGhlCiAgIElFU0cgW1JGQzIwMjhdIHVuZGVyIHRoZSBzYW1lIHJ1 bGVzIGFzIG90aGVyIElFVEYgZGVjaXNpb25zCiAgIFtSRkMyMDI2XS4KCiAgIEFsbCBhcHBy b3ZlZCByZWdpc3RyYXRpb24gZm9ybXMgYXJlIGF2YWlsYWJsZSBvbmxpbmUgaW4gdGhlIGRp cmVjdG9yeQogICBodHRwOi8vd3d3LmlhbmEub3JnL251bWJlcnMuaHRtbCB1bmRlciAibGFu Z3VhZ2VzIi4KCiAgIFVwZGF0ZXMgb3IgY2hhbmdlcyB0byBleGlzdGluZyByZWNvcmRzIGZv bGxvdyB0aGUgc2FtZSBwcm9jZWR1cmUgYXMKICAgbmV3IHJlZ2lzdHJhdGlvbnMuICBUaGUg TGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIGRlY2lkZXMgd2hldGhlcgogICB0aGVyZSBpcyBj b25zZW5zdXMgdG8gdXBkYXRlIHRoZSByZWdpc3RyYXRpb24gZm9sbG93aW5nIHRoZSB0d28g d2VlawogICByZXZpZXcgcGVyaW9kOyBub3JtYWxseSwgb2JqZWN0aW9ucyBieSB0aGUgb3Jp Z2luYWwgcmVnaXN0cmFudCB3aWxsCiAgIGNhcnJ5IGV4dHJhIHdlaWdodCBpbiBmb3JtaW5n IHN1Y2ggYSBjb25zZW5zdXMuCgogICBSZWdpc3RyYXRpb25zIGFyZSBwZXJtYW5lbnQgYW5k IHN0YWJsZS4gIE9uY2UgcmVnaXN0ZXJlZCwgc3VidGFncwogICB3aWxsIG5vdCBiZSByZW1v dmVkIGZyb20gdGhlIHJlZ2lzdHJ5IGFuZCB3aWxsIHJlbWFpbiBhIHZhbGlkIHdheSBpbgog ICB3aGljaCB0byBzcGVjaWZ5IGEgc3BlY2lmaWMgbGFuZ3VhZ2Ugb3IgdmFyaWFudC4KCiAg IE5vdGU6IFRoZSBwdXJwb3NlIG9mIHRoZSAiRGVzY3JpcHRpb24iIGluIHRoZSByZWdpc3Ry YXRpb24gZm9ybSBpcyB0bwogICBhaWQgdG8gcGVvcGxlIHRyeWluZyB0byB2ZXJpZnkgd2hl dGhlciBhIGxhbmd1YWdlIGlzIHJlZ2lzdGVyZWQgb3IKICAgd2hhdCBsYW5ndWFnZSBvciBs YW5ndWFnZSB2YXJpYXRpb24gYSBwYXJ0aWN1bGFyIHN1YnRhZyByZWZlcnMgdG8uCiAgIElu IG1vc3QgY2FzZXMsIHJlZmVyZW5jZSB0byBhbiBhdXRob3JpdGF0aXZlIGdyYW1tYXIgb3Ig ZGljdGlvbmFyeSBvZgogICB0aGF0IGxhbmd1YWdlIHdpbGwgYmUgdXNlZnVsOyBpbiBjYXNl cyB3aGVyZSBubyBzdWNoIHdvcmsgZXhpc3RzLAogICBvdGhlciB3ZWxsLWtub3duIHdvcmtz IGRlc2NyaWJpbmcgdGhhdCBsYW5ndWFnZSBvciBpbiB0aGF0IGxhbmd1YWdlCiAgIE1BWSBi ZSBhcHByb3ByaWF0ZS4gIFRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgZGVjaWRlcyB3 aGF0CiAgIGNvbnN0aXR1dGVzICJnb29kIGVub3VnaCIgcmVmZXJlbmNlIG1hdGVyaWFsLiAg VGhpcyByZXF1aXJlbWVudCBpcwogICBub3QgaW50ZW5kZWQgdG8gZXhjbHVkZSBwYXJ0aWN1 bGFyIGxhbmd1YWdlcyBvciBkaWFsZWN0cyBkdWUgdG8gdGhlCiAgIHNpemUgb2YgdGhlIHNw ZWFrZXIgcG9wdWxhdGlvbiBvciBsYWNrIG9mIGEgc3RhbmRhcmRpemVkIG9ydGhvZ3JhcGh5 LgogICBNaW5vcml0eSBsYW5ndWFnZXMgd2lsbCBiZSBjb25zaWRlcmVkIGVxdWFsbHkgb24g dGhlaXIgb3duIG1lcml0cy4KCjMuNi4gIFBvc3NpYmlsaXRpZXMgZm9yIFJlZ2lzdHJhdGlv bgoKICAgUG9zc2liaWxpdGllcyBmb3IgcmVnaXN0cmF0aW9uIG9mIHN1YnRhZ3Mgb3IgaW5m b3JtYXRpb24gYWJvdXQKICAgc3VidGFncyBpbmNsdWRlOgoKICAgbyAgUHJpbWFyeSBsYW5n dWFnZSBzdWJ0YWdzIGZvciBsYW5ndWFnZXMgbm90IGxpc3RlZCBpbiBJU08gNjM5IHRoYXQK ICAgICAgYXJlIG5vdCB2YXJpYW50cyBvZiBhbnkgbGlzdGVkIG9yIHJlZ2lzdGVyZWQgbGFu Z3VhZ2UgTUFZIGJlCiAgICAgIHJlZ2lzdGVyZWQuICBBdCB0aGUgdGltZSB0aGlzIGRvY3Vt ZW50IHdhcyBjcmVhdGVkLCB0aGVyZSB3ZXJlIG5vCiAgICAgIGV4YW1wbGVzIG9mIHRoaXMg Zm9ybSBvZiBzdWJ0YWcuICBCZWZvcmUgYXR0ZW1wdGluZyB0byByZWdpc3RlciBhCiAgICAg IGxhbmd1YWdlIHN1YnRhZywgdGhlcmUgTVVTVCBiZSBhbiBhdHRlbXB0IHRvIHJlZ2lzdGVy IHRoZSBsYW5ndWFnZQogICAgICB3aXRoIElTTyA2MzkuICBTdWJ0YWdzIE1VU1QgTk9UIGJl IHJlZ2lzdGVyZWQgZm9yIGxhbmd1YWdlcwogICAgICBkZWZpbmVkIGJ5IGNvZGVzIHRoYXQg ZXhpc3QgaW4gSVNPIDYzOS0xLCBJU08gNjM5LTIsIG9yIElTTyA2MzktMywKICAgICAgb3Ig dGhhdCBhcmUgdW5kZXIgY29uc2lkZXJhdGlvbiBieSB0aGUgSVNPIDYzOSBtYWludGVuYW5j ZSBvcgogICAgICByZWdpc3RyYXRpb24gYXV0aG9yaXRpZXMsIG9yIHRoYXQgaGF2ZSBuZXZl ciBiZWVuIGF0dGVtcHRlZCBmb3IKICAgICAgcmVnaXN0cmF0aW9uIHdpdGggdGhvc2UgYXV0 aG9yaXRpZXMuICBJZiBJU08gNjM5IGhhcyBwcmV2aW91c2x5CiAgICAgIHJlamVjdGVkIGEg bGFuZ3VhZ2UgZm9yIHJlZ2lzdHJhdGlvbiwgaXQgaXMgcmVhc29uYWJsZSB0byBhc3N1bWUK ICAgICAgdGhhdCB0aGVyZSBtdXN0IGJlIGFkZGl0aW9uYWwsIHZlcnkgY29tcGVsbGluZyBl dmlkZW5jZSBvZiBuZWVkCiAgICAgIGJlZm9yZSBpdCB3aWxsIGJlIHJlZ2lzdGVyZWQgYXMg YSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBpbiB0aGUKICAgICAgSUFOQSByZWdpc3RyeSAo dG8gdGhlIGV4dGVudCB0aGF0IGl0IGlzIHZlcnkgdW5saWtlbHkgdGhhdCBhbnkKCgoKUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMTUsIDIwMDcgICAgICAgICAg ICAgICAgW1BhZ2UgMzJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA2CgoKICAgICAgc3VidGFncyB3 aWxsIGJlIHJlZ2lzdGVyZWQgb2YgdGhpcyB0eXBlKS4KCiAgIG8gIERpYWxlY3Qgb3Igb3Ro ZXIgZGl2aXNpb25zIG9yIHZhcmlhdGlvbnMgd2l0aGluIGEgbGFuZ3VhZ2UsIGl0cwogICAg ICBvcnRob2dyYXBoeSwgd3JpdGluZyBzeXN0ZW0sIHJlZ2lvbmFsIG9yIGhpc3RvcmljYWwg dXNhZ2UsCiAgICAgIHRyYW5zbGl0ZXJhdGlvbiBvciBvdGhlciB0cmFuc2Zvcm1hdGlvbiwg b3IgZGlzdGluZ3Vpc2hpbmcKICAgICAgdmFyaWF0aW9uIE1BWSBiZSByZWdpc3RlcmVkIGFz IHZhcmlhbnQgc3VidGFncy4gIEFuIGV4YW1wbGUgaXMgdGhlCiAgICAgICdyb3phaicgc3Vi dGFnICh0aGUgUmVzaWFuIGRpYWxlY3Qgb2YgU2xvdmVuaWFuKS4KCiAgIG8gIFRoZSBhZGRp dGlvbiBvciBtYWludGVuYW5jZSBvZiBmaWVsZHMgKGdlbmVyYWxseSBvZiBhbgogICAgICBp bmZvcm1hdGlvbmFsIG5hdHVyZSkgaW4gVGFnIG9yIFN1YnRhZyByZWNvcmRzIGFzIGRlc2Ny aWJlZCBpbgogICAgICBTZWN0aW9uIDMuMSBhbmQgc3ViamVjdCB0byB0aGUgc3RhYmlsaXR5 IHByb3Zpc2lvbnMgaW4KICAgICAgU2VjdGlvbiAzLjQuICBUaGlzIGluY2x1ZGVzIGRlc2Ny aXB0aW9ucywgY29tbWVudHMsIGRlcHJlY2F0aW9uCiAgICAgIGFuZCBwcmVmZXJyZWQgdmFs dWVzIGZvciBvYnNvbGV0ZSBvciB3aXRoZHJhd24gY29kZXMsIG9yIHRoZQogICAgICBhZGRp dGlvbiBvZiBzY3JpcHQgb3IgZXh0bGFuZyBpbmZvcm1hdGlvbiB0byBwcmltYXJ5IGxhbmd1 YWdlCiAgICAgIHN1YnRhZ3MuCgogICBvICBUaGUgYWRkaXRpb24gb2YgcmVjb3JkcyBhbmQg cmVsYXRlZCBmaWVsZCB2YWx1ZSBjaGFuZ2VzIG5lY2Vzc2FyeQogICAgICB0byByZWZsZWN0 IGFzc2lnbm1lbnRzIG1hZGUgYnkgSVNPIDYzOSwgSVNPIDE1OTI0LCBJU08gMzE2NiwgYW5k CiAgICAgIFVOIE0uNDkgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy40LgoKICAgU3VidGFn cyBwcm9wb3NlZCBmb3IgcmVnaXN0cmF0aW9uIHRoYXQgd291bGQgY2F1c2UgYWxsIG9yIHBh cnQgb2YgYQogICBncmFuZGZhdGhlcmVkIHRhZyB0byBiZWNvbWUgcmVkdW5kYW50IGJ1dCB3 aG9zZSBtZWFuaW5nIGNvbmZsaWN0cwogICB3aXRoIG9yIGFsdGVycyB0aGUgbWVhbmluZyBv ZiB0aGUgZ3JhbmRmYXRoZXJlZCB0YWcgTVVTVCBiZSByZWplY3RlZC4KCiAgIFRoaXMgZG9j dW1lbnQgbGVhdmVzIHRoZSBkZWNpc2lvbiBvbiB3aGF0IHN1YnRhZ3Mgb3IgY2hhbmdlcyB0 bwogICBzdWJ0YWdzIGFyZSBhcHByb3ByaWF0ZSAob3Igbm90KSB0byB0aGUgcmVnaXN0cmF0 aW9uIHByb2Nlc3MKICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy41LgoKICAgTm90ZTogZm91 ci1jaGFyYWN0ZXIgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzIGFyZSByZXNlcnZlZCB0byBh bGxvdwogICBmb3IgdGhlIHBvc3NpYmlsaXR5IG9mIGFscGhhNCBjb2RlcyBpbiBzb21lIGZ1 dHVyZSBhZGRpdGlvbiB0byB0aGUKICAgSVNPIDYzOSBmYW1pbHkgb2Ygc3RhbmRhcmRzLgoK ICAgSVNPIDYzOSBkZWZpbmVzIGEgbWFpbnRlbmFuY2UgYWdlbmN5IGZvciBhZGRpdGlvbnMg dG8gYW5kIGNoYW5nZXMgaW4KICAgdGhlIGxpc3Qgb2YgbGFuZ3VhZ2VzIGluIElTTyA2Mzku ICBUaGlzIGFnZW5jeSBpczoKCiAgIEludGVybmF0aW9uYWwgSW5mb3JtYXRpb24gQ2VudHJl IGZvciBUZXJtaW5vbG9neSAoSW5mb3Rlcm0pCiAgIEFpY2hob2x6Z2Fzc2UgNi8xMiwgQVQt MTEyMAogICBXaWVuLCBBdXN0cmlhCiAgIFBob25lOiArNDMgMSAyNiA3NSAzNSBFeHQuIDMx MiBGYXg6ICs0MyAxIDIxNiAzMiA3MgoKICAgSVNPIDYzOS0yIGRlZmluZXMgYSBtYWludGVu YW5jZSBhZ2VuY3kgZm9yIGFkZGl0aW9ucyB0byBhbmQgY2hhbmdlcwogICBpbiB0aGUgbGlz dCBvZiBsYW5ndWFnZXMgaW4gSVNPIDYzOS0yLiAgVGhpcyBhZ2VuY3kgaXM6CgogICBMaWJy YXJ5IG9mIENvbmdyZXNzCiAgIE5ldHdvcmsgRGV2ZWxvcG1lbnQgYW5kIE1BUkMgU3RhbmRh cmRzIE9mZmljZQogICBXYXNoaW5ndG9uLCBELkMuIDIwNTQwIFVTQQogICBQaG9uZTogKzEg MjAyIDcwNyA2MjM3IEZheDogKzEgMjAyIDcwNyAwMTE1CiAgIFVSTDogaHR0cDovL3d3dy5s b2MuZ292L3N0YW5kYXJkcy9pc282MzktMgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAg RXhwaXJlcyBNYXJjaCAxNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAzM10KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg U2VwdGVtYmVyIDIwMDYKCgogICBJU08gNjM5LTMgZGVmaW5lcyBhIG1haW50ZW5hbmNlIGFn ZW5jeSBmb3IgYWRkaXRpb25zIHRvIGFuZCBjaGFuZ2VzCiAgIGluIHRoZSBsaXN0IG9mIGxh bmd1YWdlcyBpbiBJU08gNjM5LTMuICBUaGlzIGFnZW5jeSBpczoKCiAgIFNJTCBJbnRlcm5h dGlvbmFsCiAgIElTTyA2MzktMyBSZWdpc3RyYXIKICAgNzUwMCBXLiBDYW1wIFdpc2RvbSBS ZC4KICAgRGFsbGFzLCBUWCA3NTIzNiBVU0EKICAgUGhvbmU6ICsxIDk3MiA3MDggNzQwMCwg ZXh0LiAyMjkzIEZheDogKzEgOTcyIDcwOCA3NTQ2CiAgIEVtYWlsOiBpc282MzktM0BzaWwu b3JnCiAgIFVSTDogaHR0cDovL3d3dy5zaWwub3JnL2lzbzYzOS0zCgogICBUaGUgbWFpbnRl bmFuY2UgYWdlbmN5IGZvciBJU08gMzE2NiAoY291bnRyeSBjb2RlcykgaXM6CgogICBJU08g MzE2NiBNYWludGVuYW5jZSBBZ2VuY3kKICAgYy9vIEludGVybmF0aW9uYWwgT3JnYW5pemF0 aW9uIGZvciBTdGFuZGFyZGl6YXRpb24KICAgQ2FzZSBwb3N0YWxlIDU2CiAgIENILTEyMTEg R2VuZXZhIDIwIFN3aXR6ZXJsYW5kCiAgIFBob25lOiArNDEgMjIgNzQ5IDcyIDMzIEZheDog KzQxIDIyIDc0OSA3MyA0OQogICBVUkw6IGh0dHA6Ly93d3cuaXNvLm9yZy9pc28vZW4vcHJv ZHMtc2VydmljZXMvaXNvMzE2Nm1hL2luZGV4Lmh0bWwKCiAgIFRoZSByZWdpc3RyYXRpb24g YXV0aG9yaXR5IGZvciBJU08gMTU5MjQgKHNjcmlwdCBjb2RlcykgaXM6CgogICBVbmljb2Rl IENvbnNvcnRpdW0gQm94IDM5MTQ3NgogICBNb3VudGFpbiBWaWV3LCBDQSA5NDAzOS0xNDc2 LCBVU0EKICAgVVJMOiBodHRwOi8vd3d3LnVuaWNvZGUub3JnL2lzbzE1OTI0CgogICBUaGUg U3RhdGlzdGljcyBEaXZpc2lvbiBvZiB0aGUgVW5pdGVkIE5hdGlvbnMgU2VjcmV0YXJpYXQg bWFpbnRhaW5zCiAgIHRoZSBTdGFuZGFyZCBDb3VudHJ5IG9yIEFyZWEgQ29kZXMgZm9yIFN0 YXRpc3RpY2FsIFVzZSBhbmQgY2FuIGJlCiAgIHJlYWNoZWQgYXQ6CgogICBTdGF0aXN0aWNh bCBTZXJ2aWNlcyBCcmFuY2gKICAgU3RhdGlzdGljcyBEaXZpc2lvbgogICBVbml0ZWQgTmF0 aW9ucywgUm9vbSBEQzItMTYyMAogICBOZXcgWW9yaywgTlkgMTAwMTcsIFVTQQoKICAgRmF4 OiArMS0yMTItOTYzLTA2MjMKICAgRS1tYWlsOiBzdGF0aXN0aWNzQHVuLm9yZwogICBVUkw6 IGh0dHA6Ly91bnN0YXRzLnVuLm9yZy91bnNkL21ldGhvZHMvbTQ5L200OWFscGhhLmh0bQoK My43LiAgRXh0ZW5zaW9ucyBhbmQgRXh0ZW5zaW9ucyBSZWdpc3RyeQoKICAgRXh0ZW5zaW9u IHN1YnRhZ3MgYXJlIHRob3NlIGludHJvZHVjZWQgYnkgc2luZ2xlLWNoYXJhY3RlciBzdWJ0 YWdzCiAgICgic2luZ2xldG9ucyIpIG90aGVyIHRoYW4gJ3gnLiAgVGhleSBhcmUgcmVzZXJ2 ZWQgZm9yIHRoZSBnZW5lcmF0aW9uCiAgIG9mIGlkZW50aWZpZXJzIHRoYXQgY29udGFpbiBh IGxhbmd1YWdlIGNvbXBvbmVudCBhbmQgYXJlIGNvbXBhdGlibGUKICAgd2l0aCBhcHBsaWNh dGlvbnMgdGhhdCB1bmRlcnN0YW5kIGxhbmd1YWdlIHRhZ3MuCgogICBUaGUgc3RydWN0dXJl IGFuZCBmb3JtIG9mIGV4dGVuc2lvbnMgYXJlIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudCBz bwogICB0aGF0IGltcGxlbWVudGF0aW9ucyBjYW4gYmUgY3JlYXRlZCB0aGF0IGFyZSBmb3J3 YXJkIGNvbXBhdGlibGUgd2l0aAoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJl cyBNYXJjaCAxNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAzNF0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVt YmVyIDIwMDYKCgogICBhcHBsaWNhdGlvbnMgdGhhdCBtaWdodCBiZSBjcmVhdGVkIHVzaW5n IHNpbmdsZXRvbnMgaW4gdGhlIGZ1dHVyZS4KICAgSW4gYWRkaXRpb24sIGRlZmluaW5nIGEg bWVjaGFuaXNtIGZvciBtYWludGFpbmluZyBzaW5nbGV0b25zIHdpbGwKICAgbGVuZCBzdGFi aWxpdHkgdG8gdGhpcyBkb2N1bWVudCBieSByZWR1Y2luZyB0aGUgbGlrZWx5IG5lZWQgZm9y CiAgIGZ1dHVyZSByZXZpc2lvbnMgb3IgdXBkYXRlcy4KCiAgIFNpbmdsZS1jaGFyYWN0ZXIg c3VidGFncyBhcmUgYXNzaWduZWQgYnkgSUFOQSB1c2luZyB0aGUgIklFVEYKICAgQ29uc2Vu c3VzIiBwb2xpY3kgZGVmaW5lZCBieSBbUkZDMjQzNF0uICBUaGlzIHBvbGljeSByZXF1aXJl cyB0aGUKICAgZGV2ZWxvcG1lbnQgb2YgYW4gUkZDLCB3aGljaCBTSEFMTCBkZWZpbmUgdGhl IG5hbWUsIHB1cnBvc2UsCiAgIHByb2Nlc3NlcywgYW5kIHByb2NlZHVyZXMgZm9yIG1haW50 YWluaW5nIHRoZSBzdWJ0YWdzLiAgVGhlCiAgIG1haW50YWluaW5nIG9yIHJlZ2lzdGVyaW5n IGF1dGhvcml0eSwgaW5jbHVkaW5nIG5hbWUsIGNvbnRhY3QgZW1haWwsCiAgIGRpc2N1c3Np b24gbGlzdCBlbWFpbCwgYW5kIFVSTCBsb2NhdGlvbiBvZiB0aGUgcmVnaXN0cnksIE1VU1Qg YmUKICAgaW5kaWNhdGVkIGNsZWFybHkgaW4gdGhlIFJGQy4gIFRoZSBSRkMgTVVTVCBzcGVj aWZ5IG9yIGluY2x1ZGUgZWFjaAogICBvZiB0aGUgZm9sbG93aW5nOgoKICAgbyAgVGhlIHNw ZWNpZmljYXRpb24gTVVTVCByZWZlcmVuY2UgdGhlIHNwZWNpZmljIHZlcnNpb24gb3IgcmV2 aXNpb24KICAgICAgb2YgdGhpcyBkb2N1bWVudCB0aGF0IGdvdmVybnMgaXRzIGNyZWF0aW9u IGFuZCBNVVNUIHJlZmVyZW5jZSB0aGlzCiAgICAgIHNlY3Rpb24gb2YgdGhpcyBkb2N1bWVu dC4KCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIGFuZCBhbGwgc3VidGFncyBkZWZpbmVkIGJ5 IHRoZSBzcGVjaWZpY2F0aW9uCiAgICAgIE1VU1QgZm9sbG93IHRoZSBBQk5GIGFuZCBvdGhl ciBydWxlcyBmb3IgdGhlIGZvcm1hdGlvbiBvZiB0YWdzIGFuZAogICAgICBzdWJ0YWdzIGFz IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4gIEluIHBhcnRpY3VsYXIsIGl0IE1VU1QKICAg ICAgc3BlY2lmeSB0aGF0IGNhc2UgaXMgbm90IHNpZ25pZmljYW50IGFuZCB0aGF0IHN1YnRh Z3MgTVVTVCBOT1QKICAgICAgZXhjZWVkIGVpZ2h0IGNoYXJhY3RlcnMgaW4gbGVuZ3RoLgoK ICAgbyAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCBzcGVjaWZ5IGEgY2Fub25pY2FsIHJlcHJl c2VudGF0aW9uLgoKICAgbyAgVGhlIHNwZWNpZmljYXRpb24gb2YgdmFsaWQgc3VidGFncyBN VVNUIGJlIGF2YWlsYWJsZSBvdmVyIHRoZQogICAgICBJbnRlcm5ldCBhbmQgYXQgbm8gY29z dC4KCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1VU1QgYmUgaW4gdGhlIHB1YmxpYyBkb21h aW4gb3IgYXZhaWxhYmxlIHZpYSBhCiAgICAgIHJveWFsdHktZnJlZSBsaWNlbnNlIGFjY2Vw dGFibGUgdG8gdGhlIElFVEYgYW5kIHNwZWNpZmllZCBpbiB0aGUKICAgICAgUkZDLgoKICAg byAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCBiZSB2ZXJzaW9uZWQsIGFuZCBlYWNoIHZlcnNp b24gb2YgdGhlCiAgICAgIHNwZWNpZmljYXRpb24gTVVTVCBiZSBudW1iZXJlZCwgZGF0ZWQs IGFuZCBzdGFibGUuCgogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBNVVNUIGJlIHN0YWJsZS4g IFRoYXQgaXMsIGV4dGVuc2lvbiBzdWJ0YWdzLAogICAgICBvbmNlIGRlZmluZWQgYnkgYSBz cGVjaWZpY2F0aW9uLCBNVVNUIE5PVCBiZSByZXRyYWN0ZWQgb3IgY2hhbmdlCiAgICAgIGlu IG1lYW5pbmcgaW4gYW55IHN1YnN0YW50aWFsIHdheS4KCiAgIG8gIFRoZSBzcGVjaWZpY2F0 aW9uIE1VU1QgaW5jbHVkZSBpbiBhIHNlcGFyYXRlIHNlY3Rpb24gdGhlCiAgICAgIHJlZ2lz dHJhdGlvbiBmb3JtIHJlcHJvZHVjZWQgaW4gdGhpcyBzZWN0aW9uIChiZWxvdykgdG8gYmUg dXNlZCBpbgogICAgICByZWdpc3RlcmluZyB0aGUgZXh0ZW5zaW9uIHVwb24gcHVibGljYXRp b24gYXMgYW4gUkZDLgoKICAgbyAgSUFOQSBNVVNUIGJlIGluZm9ybWVkIG9mIGNoYW5nZXMg dG8gdGhlIGNvbnRhY3QgaW5mb3JtYXRpb24gYW5kCiAgICAgIFVSTCBmb3IgdGhlIHNwZWNp ZmljYXRpb24uCgogICBJQU5BIHdpbGwgbWFpbnRhaW4gYSByZWdpc3RyeSBvZiBhbGxvY2F0 ZWQgc2luZ2xlLWNoYXJhY3RlcgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJl cyBNYXJjaCAxNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAzNV0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVt YmVyIDIwMDYKCgogICAoc2luZ2xldG9uKSBzdWJ0YWdzLiAgVGhpcyByZWdpc3RyeSBNVVNU IHVzZSB0aGUgcmVjb3JkLWphciBmb3JtYXQKICAgZGVzY3JpYmVkIGJ5IHRoZSBBQk5GIGlu IFNlY3Rpb24gMy4xLiAgVXBvbiBwdWJsaWNhdGlvbiBvZiBhbgogICBleHRlbnNpb24gYXMg YW4gUkZDLCB0aGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5IGRlZmluZWQgaW4gdGhlIFJGQwog ICBNVVNUIGZvcndhcmQgdGhpcyByZWdpc3RyYXRpb24gZm9ybSB0byBpZXNnQGlldGYub3Jn LCB3aG8gTVVTVAogICBmb3J3YXJkIHRoZSByZXF1ZXN0IHRvIGlhbmFAaWFuYS5vcmcuICBU aGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5IG9mCiAgIHRoZSBleHRlbnNpb24gTVVTVCBtYWlu dGFpbiB0aGUgYWNjdXJhY3kgb2YgdGhlIHJlY29yZCBieSBzZW5kaW5nIGFuCiAgIHVwZGF0 ZWQgZnVsbCBjb3B5IG9mIHRoZSByZWNvcmQgdG8gaWFuYUBpYW5hLm9yZyB3aXRoIHRoZSBz dWJqZWN0CiAgIGxpbmUgIkxBTkdVQUdFIFRBRyBFWFRFTlNJT04gVVBEQVRFIiB3aGVuZXZl ciBjb250ZW50IGNoYW5nZXMuICBPbmx5CiAgIHRoZSAnQ29tbWVudHMnLCAnQ29udGFjdF9F bWFpbCcsICdNYWlsaW5nX0xpc3QnLCBhbmQgJ1VSTCcgZmllbGRzIE1BWQogICBiZSBtb2Rp ZmllZCBpbiB0aGVzZSB1cGRhdGVzLgoKICAgRmFpbHVyZSB0byBtYWludGFpbiB0aGlzIHJl Y29yZCwgbWFpbnRhaW4gdGhlIGNvcnJlc3BvbmRpbmcgcmVnaXN0cnksCiAgIG9yIG1lZXQg b3RoZXIgY29uZGl0aW9ucyBpbXBvc2VkIGJ5IHRoaXMgc2VjdGlvbiBvZiB0aGlzIGRvY3Vt ZW50IE1BWQogICBiZSBhcHBlYWxlZCB0byB0aGUgSUVTRyBbUkZDMjAyOF0gdW5kZXIgdGhl IHNhbWUgcnVsZXMgYXMgb3RoZXIgSUVURgogICBkZWNpc2lvbnMgKHNlZSBbUkZDMjAyNl0p IGFuZCBNQVkgcmVzdWx0IGluIHRoZSBhdXRob3JpdHkgdG8gbWFpbnRhaW4KICAgdGhlIGV4 dGVuc2lvbiBiZWluZyB3aXRoZHJhd24gb3IgcmVhc3NpZ25lZCBieSB0aGUgSUVTRy4KICAg JSUKICAgSWRlbnRpZmllcjoKICAgRGVzY3JpcHRpb246CiAgIENvbW1lbnRzOgogICBBZGRl ZDoKICAgUkZDOgogICBBdXRob3JpdHk6CiAgIENvbnRhY3RfRW1haWw6CiAgIE1haWxpbmdf TGlzdDoKICAgVVJMOgogICAlJQoKICAgRmlndXJlIDY6IEZvcm1hdCBvZiBSZWNvcmRzIGlu IHRoZSBMYW5ndWFnZSBUYWcgRXh0ZW5zaW9ucyBSZWdpc3RyeQoKICAgJ0lkZW50aWZpZXIn IGNvbnRhaW5zIHRoZSBzaW5nbGUtY2hhcmFjdGVyIHN1YnRhZyAoc2luZ2xldG9uKQogICBh c3NpZ25lZCB0byB0aGUgZXh0ZW5zaW9uLiAgVGhlIEludGVybmV0LURyYWZ0IHN1Ym1pdHRl ZCB0byBkZWZpbmUKICAgdGhlIGV4dGVuc2lvbiBTSE9VTEQgc3BlY2lmeSB3aGljaCBsZXR0 ZXIgb3IgZGlnaXQgdG8gdXNlLCBhbHRob3VnaAogICB0aGUgSUVTRyBNQVkgY2hhbmdlIHRo ZSBhc3NpZ25tZW50IHdoZW4gYXBwcm92aW5nIHRoZSBSRkMuCgogICAnRGVzY3JpcHRpb24n IGNvbnRhaW5zIHRoZSBuYW1lIGFuZCBkZXNjcmlwdGlvbiBvZiB0aGUgZXh0ZW5zaW9uLgoK ICAgJ0NvbW1lbnRzJyBpcyBhbiBPUFRJT05BTCBmaWVsZCBhbmQgTUFZIGNvbnRhaW4gYSBi cm9hZGVyIGRlc2NyaXB0aW9uCiAgIG9mIHRoZSBleHRlbnNpb24uCgogICAnQWRkZWQnIGNv bnRhaW5zIHRoZSBkYXRlIHRoZSBSRkMgd2FzIHB1Ymxpc2hlZCBpbiB0aGUgImZ1bGwtZGF0 ZSIKICAgZm9ybWF0IHNwZWNpZmllZCBpbiBbUkZDMzMzOV0uICBGb3IgZXhhbXBsZTogMjAw NC0wNi0yOCByZXByZXNlbnRzCiAgIEp1bmUgMjgsIDIwMDQsIGluIHRoZSBHcmVnb3JpYW4g Y2FsZW5kYXIuCgogICAnUkZDJyBjb250YWlucyB0aGUgUkZDIG51bWJlciBhc3NpZ25lZCB0 byB0aGUgZXh0ZW5zaW9uLgoKICAgJ0F1dGhvcml0eScgY29udGFpbnMgdGhlIG5hbWUgb2Yg dGhlIG1haW50YWluaW5nIGF1dGhvcml0eSBmb3IgdGhlCiAgIGV4dGVuc2lvbi4KCgoKUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMTUsIDIwMDcgICAgICAgICAg ICAgICAgW1BhZ2UgMzZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA2CgoKICAgJ0NvbnRhY3RfRW1h aWwnIGNvbnRhaW5zIHRoZSBlbWFpbCBhZGRyZXNzIHVzZWQgdG8gY29udGFjdCB0aGUKICAg bWFpbnRhaW5pbmcgYXV0aG9yaXR5LgoKICAgJ01haWxpbmdfTGlzdCcgY29udGFpbnMgdGhl IFVSTCBvciBzdWJzY3JpcHRpb24gZW1haWwgYWRkcmVzcyBvZiB0aGUKICAgbWFpbGluZyBs aXN0IHVzZWQgYnkgdGhlIG1haW50YWluaW5nIGF1dGhvcml0eS4KCiAgICdVUkwnIGNvbnRh aW5zIHRoZSBVUkwgb2YgdGhlIHJlZ2lzdHJ5IGZvciB0aGlzIGV4dGVuc2lvbi4KCiAgIFRo ZSBkZXRlcm1pbmF0aW9uIG9mIHdoZXRoZXIgYW4gSW50ZXJuZXQtRHJhZnQgbWVldHMgdGhl IGFib3ZlCiAgIGNvbmRpdGlvbnMgYW5kIHRoZSBkZWNpc2lvbiB0byBncmFudCBvciB3aXRo aG9sZCBzdWNoIGF1dGhvcml0eSByZXN0cwogICBzb2xlbHkgd2l0aCB0aGUgSUVTRyBhbmQg aXMgc3ViamVjdCB0byB0aGUgbm9ybWFsIHJldmlldyBhbmQgYXBwZWFscwogICBwcm9jZXNz IGFzc29jaWF0ZWQgd2l0aCB0aGUgUkZDIHByb2Nlc3MuCgogICBFeHRlbnNpb24gYXV0aG9y cyBhcmUgc3Ryb25nbHkgY2F1dGlvbmVkIHRoYXQgbWFueSAoaW5jbHVkaW5nIG1vc3QKICAg d2VsbC1mb3JtZWQpIHByb2Nlc3NvcnMgd2lsbCBiZSB1bmF3YXJlIG9mIGFueSBzcGVjaWFs IHJlbGF0aW9uc2hpcHMKICAgb3IgbWVhbmluZyBpbmhlcmVudCBpbiB0aGUgb3JkZXIgb2Yg ZXh0ZW5zaW9uIHN1YnRhZ3MuICBFeHRlbnNpb24KICAgYXV0aG9ycyBTSE9VTEQgYXZvaWQg c3VidGFnIHJlbGF0aW9uc2hpcHMgb3IgY2Fub25pY2FsaXphdGlvbgogICBtZWNoYW5pc21z IHRoYXQgaW50ZXJmZXJlIHdpdGggbWF0Y2hpbmcgb3Igd2l0aCBsZW5ndGggcmVzdHJpY3Rp b25zCiAgIHRoYXQgc29tZXRpbWVzIGV4aXN0IGluIGNvbW1vbiBwcm90b2NvbHMgd2hlcmUg dGhlIGV4dGVuc2lvbiBpcyB1c2VkLgogICBJbiBwYXJ0aWN1bGFyLCBhcHBsaWNhdGlvbnMg TUFZIHRydW5jYXRlIHRoZSBzdWJ0YWdzIGluIGRvaW5nCiAgIG1hdGNoaW5nIG9yIGluIGZp dHRpbmcgaW50byBsaW1pdGVkIGxlbmd0aHMsIHNvIGl0IGlzIFJFQ09NTUVOREVECiAgIHRo YXQgdGhlIG1vc3Qgc2lnbmlmaWNhbnQgaW5mb3JtYXRpb24gYmUgaW4gdGhlIG1vc3Qgc2ln bmlmaWNhbnQKICAgKGxlZnQtbW9zdCkgc3VidGFncyBhbmQgdGhhdCB0aGUgc3BlY2lmaWNh dGlvbiBncmFjZWZ1bGx5IGhhbmRsZQogICB0cnVuY2F0ZWQgc3VidGFncy4KCiAgIFdoZW4g YSBsYW5ndWFnZSB0YWcgaXMgdG8gYmUgdXNlZCBpbiBhIHNwZWNpZmljLCBrbm93biwgcHJv dG9jb2wsIGl0CiAgIGlzIFJFQ09NTUVOREVEIHRoYXQgdGhhdCB0aGUgbGFuZ3VhZ2UgdGFn IG5vdCBjb250YWluIGV4dGVuc2lvbnMgbm90CiAgIHN1cHBvcnRlZCBieSB0aGF0IHByb3Rv Y29sLiAgSW4gYWRkaXRpb24sIG5vdGUgdGhhdCBzb21lIHByb3RvY29scwogICBNQVkgaW1w b3NlIHVwcGVyIGxpbWl0cyBvbiB0aGUgbGVuZ3RoIG9mIHRoZSBzdHJpbmdzIHVzZWQgdG8g c3RvcmUgb3IKICAgdHJhbnNwb3J0IHRoZSBsYW5ndWFnZSB0YWcuCgozLjguICBVcGRhdGUg b2YgdGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeQoKICAgVXBvbiBhZG9wdGlvbiBvZiB0 aGlzIGRvY3VtZW50IHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSB3aWxsCiAg IG5lZWQgYW4gdXBkYXRlIHNvIHRoYXQgaXQgY29udGFpbnMgdGhlIGNvbXBsZXRlIHNldCBv ZiBzdWJ0YWdzIHZhbGlkCiAgIGluIGEgbGFuZ3VhZ2UgdGFnLiAgVGhpcyBjb2xsZWN0aW9u IG9mIHN1YnRhZ3MsIGFsb25nIHdpdGggYQogICBkZXNjcmlwdGlvbiBvZiB0aGUgcHJvY2Vz cyB1c2VkIHRvIGNyZWF0ZSBpdCwgaXMgZGVzY3JpYmVkIGJ5CiAgIFtpbml0aWFsLXJlZ2lz dHJ5XS4gIElBTkEgU0hBTEwgcHVibGlzaCB0aGUgdXBkYXRlZCB2ZXJzaW9uIG9mIHRoZQog ICByZWdpc3RyeSBkZXNjcmliZWQgYnkgdGhpcyBkb2N1bWVudCB1c2luZyB0aGUgaW5zdHJ1 Y3Rpb25zIGFuZAogICBjb250ZW50IG9mIFtpbml0aWFsLXJlZ2lzdHJ5XS4gIE9uY2UgcHVi bGlzaGVkIGJ5IElBTkEsIHRoZQogICBtYWludGVuYW5jZSBwcm9jZWR1cmVzLCBydWxlcywg YW5kIHJlZ2lzdHJhdGlvbiBwcm9jZXNzZXMgZGVzY3JpYmVkCiAgIGluIHRoaXMgZG9jdW1l bnQgd2lsbCBiZSBhdmFpbGFibGUgZm9yIG5ldyByZWdpc3RyYXRpb25zIG9yIHVwZGF0ZXMu CgogICBSZWdpc3RyYXRpb25zIHRoYXQgYXJlIGluIHByb2Nlc3MgdW5kZXIgdGhlIHJ1bGVz IGRlZmluZWQgaW4KICAgW1JGQzQ2NDZdIHdoZW4gdGhpcyBkb2N1bWVudCBpcyBhZG9wdGVk IE1VU1QgYmUgY29tcGxldGVkIHVuZGVyIHRoZQogICBydWxlcyBjb250YWluZWQgaW4gdGhp cyBkb2N1bWVudC4KCgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJj aCAxNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAzN10KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIw MDYKCgo0LiAgRm9ybWF0aW9uIGFuZCBQcm9jZXNzaW5nIG9mIExhbmd1YWdlIFRhZ3MKCiAg IFRoaXMgc2VjdGlvbiBhZGRyZXNzZXMgaG93IHRvIHVzZSB0aGUgaW5mb3JtYXRpb24gaW4g dGhlIHJlZ2lzdHJ5CiAgIHdpdGggdGhlIHRhZyBzeW50YXggdG8gY2hvb3NlLCBmb3JtLCBh bmQgcHJvY2VzcyBsYW5ndWFnZSB0YWdzLgoKNC4xLiAgQ2hvaWNlIG9mIExhbmd1YWdlIFRh ZwoKICAgT25lIGlzIHNvbWV0aW1lcyBmYWNlZCB3aXRoIHRoZSBjaG9pY2UgYmV0d2VlbiBz ZXZlcmFsIHBvc3NpYmxlIHRhZ3MKICAgZm9yIHRoZSBzYW1lIGJvZHkgb2YgdGV4dC4KCiAg IEludGVyb3BlcmFiaWxpdHkgaXMgYmVzdCBzZXJ2ZWQgd2hlbiBhbGwgdXNlcnMgdXNlIHRo ZSBzYW1lIGxhbmd1YWdlCiAgIHRhZyBpbiBvcmRlciB0byByZXByZXNlbnQgdGhlIHNhbWUg bGFuZ3VhZ2UuICBJZiBhbiBhcHBsaWNhdGlvbiBoYXMKICAgcmVxdWlyZW1lbnRzIHRoYXQg bWFrZSB0aGUgcnVsZXMgaGVyZSBpbmFwcGxpY2FibGUsIHRoZW4gdGhhdAogICBhcHBsaWNh dGlvbiByaXNrcyBkYW1hZ2luZyBpbnRlcm9wZXJhYmlsaXR5LiAgSXQgaXMgc3Ryb25nbHkK ICAgUkVDT01NRU5ERUQgdGhhdCB1c2VycyBub3QgZGVmaW5lIHRoZWlyIG93biBydWxlcyBm b3IgbGFuZ3VhZ2UgdGFnCiAgIGNob2ljZS4KCiAgIFN1YnRhZ3MgU0hPVUxEIG9ubHkgYmUg dXNlZCB3aGVyZSB0aGV5IGFkZCB1c2VmdWwgZGlzdGluZ3Vpc2hpbmcKICAgaW5mb3JtYXRp b247IGV4dHJhbmVvdXMgc3VidGFncyBpbnRlcmZlcmUgd2l0aCB0aGUgbWVhbmluZywKICAg dW5kZXJzdGFuZGluZywgYW5kIHByb2Nlc3Npbmcgb2YgbGFuZ3VhZ2UgdGFncy4gIEluIHBh cnRpY3VsYXIsIHVzZXJzCiAgIGFuZCBpbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGZvbGxvdyB0 aGUgJ1ByZWZpeCcgYW5kICdTdXBwcmVzcy1TY3JpcHQnCiAgIGZpZWxkcyBpbiB0aGUgcmVn aXN0cnkgKGRlZmluZWQgaW4gU2VjdGlvbiAzLjEpOiB0aGVzZSBmaWVsZHMgcHJvdmlkZQog ICBndWlkYW5jZSBvbiB3aGVuIHNwZWNpZmljIGFkZGl0aW9uYWwgc3VidGFncyBTSE9VTEQg KGFuZCBTSE9VTEQgTk9UKQogICBiZSB1c2VkIGluIGEgbGFuZ3VhZ2UgdGFnLgoKICAgT2Yg cGFydGljdWxhciBub3RlLCBtYW55IGFwcGxpY2F0aW9ucyBjYW4gYmVuZWZpdCBmcm9tIHRo ZSB1c2Ugb2YKICAgc2NyaXB0IHN1YnRhZ3MgaW4gbGFuZ3VhZ2UgdGFncywgYXMgbG9uZyBh cyB0aGUgdXNlIGlzIGNvbnNpc3RlbnQgZm9yCiAgIGEgZ2l2ZW4gY29udGV4dC4gIFNjcmlw dCBzdWJ0YWdzIHdlcmUgbm90IGZvcm1hbGx5IGRlZmluZWQgaW4gUkZDCiAgIDMwNjYgYW5k IHRoZWlyIHVzZSBjYW4gYWZmZWN0IG1hdGNoaW5nIGFuZCBzdWJ0YWcgaWRlbnRpZmljYXRp b24gYnkKICAgaW1wbGVtZW50YXRpb25zIG9mIFJGQyAzMDY2LCBhcyB0aGVzZSBzdWJ0YWdz IGFwcGVhciBiZXR3ZWVuIHRoZQogICBwcmltYXJ5IGxhbmd1YWdlIGFuZCByZWdpb24gc3Vi dGFncy4gIEZvciBleGFtcGxlLCBpZiBhIHVzZXIgcmVxdWVzdHMKICAgY29udGVudCBpbiBh biBpbXBsZW1lbnRhdGlvbiBvZiBTZWN0aW9uIDIuNSBvZiBbUkZDMzA2Nl0gdXNpbmcgdGhl CiAgIGxhbmd1YWdlIHJhbmdlICJlbi1VUyIsIGNvbnRlbnQgbGFiZWxlZCAiZW4tTGF0bi1V UyIgd2lsbCBub3QgbWF0Y2gKICAgdGhlIHJlcXVlc3QuICBUaGVyZWZvcmUsIGl0IGlzIGlt cG9ydGFudCB0byBrbm93IHdoZW4gc2NyaXB0IHN1YnRhZ3MKICAgd2lsbCBjdXN0b21hcmls eSBiZSB1c2VkIGFuZCB3aGVuIHRoZXkgb3VnaHQgbm90IGJlIHVzZWQuICBJbiB0aGUKICAg cmVnaXN0cnksIHRoZSBTdXBwcmVzcy1TY3JpcHQgZmllbGQgaGVscHMgZW5zdXJlIGdyZWF0 ZXIKICAgY29tcGF0aWJpbGl0eSBiZXR3ZWVuIHRoZSBsYW5ndWFnZSB0YWdzIGdlbmVyYXRl ZCBhY2NvcmRpbmcgdG8gdGhlCiAgIHJ1bGVzIGluIHRoaXMgZG9jdW1lbnQgYW5kIGxhbmd1 YWdlIHRhZ3MgYW5kIHRhZyBwcm9jZXNzb3JzIG9yCiAgIGNvbnN1bWVycyBiYXNlZCBvbiBS RkMgMzA2NiBieSBkZWZpbmluZyB3aGVuIHVzZXJzIFNIT1VMRCBOT1QgaW5jbHVkZQogICBh IHNjcmlwdCBzdWJ0YWcgd2l0aCBhIHBhcnRpY3VsYXIgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0 YWcuCgogICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzICh0eXBlICdleHRsYW5nJyBpbiB0 aGUgcmVnaXN0cnk7IHNlZQogICBTZWN0aW9uIDMuMSkgYWxzbyBhcHBlYXIgYmV0d2VlbiB0 aGUgcHJpbWFyeSBsYW5ndWFnZSBhbmQgcmVnaW9uCiAgIHN1YnRhZ3MuICBBcHBsaWNhdGlv bnMgbWlnaHQgYmVuZWZpdCBmcm9tIHRoZWlyIGp1ZGljaW91cyB1c2UgaW4KICAgZm9ybWlu ZyBsYW5ndWFnZSB0YWdzLiBbWyBndWlkZWxpbmVzIGhlcmU/PyBdXQoKICAgU3RhbmRhcmRz LCBwcm90b2NvbHMsIGFuZCBhcHBsaWNhdGlvbnMgdGhhdCByZWZlcmVuY2UgdGhpcyBkb2N1 bWVudAogICBub3JtYXRpdmVseSBidXQgYXBwbHkgZGlmZmVyZW50IHJ1bGVzIHRvIHRoZSBv bmVzIGdpdmVuIGluIHRoaXMKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMg TWFyY2ggMTUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMzhdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJl ciAyMDA2CgoKICAgc2VjdGlvbiBNVVNUIHNwZWNpZnkgaG93IHRoZSBwcm9jZWR1cmUgdmFy aWVzIGZyb20gdGhlIG9uZSBnaXZlbgogICBoZXJlLgoKICAgVGhlIGNob2ljZSBvZiBzdWJ0 YWdzIHVzZWQgdG8gZm9ybSBhIGxhbmd1YWdlIHRhZyBTSE9VTEQgYmUgZ3VpZGVkIGJ5CiAg IHRoZSBmb2xsb3dpbmcgcnVsZXM6CgogICAxLiAgVXNlIGFzIHByZWNpc2UgYSB0YWcgYXMg cG9zc2libGUsIGJ1dCBubyBtb3JlIHNwZWNpZmljIHRoYW4gaXMKICAgICAgIGp1c3RpZmll ZC4gIEF2b2lkIHVzaW5nIHN1YnRhZ3MgdGhhdCBhcmUgbm90IGltcG9ydGFudCBmb3IKICAg ICAgIGRpc3Rpbmd1aXNoaW5nIGNvbnRlbnQgaW4gYW4gYXBwbGljYXRpb24uCgogICAgICAg KiAgRm9yIGV4YW1wbGUsICdkZScgbWlnaHQgc3VmZmljZSBmb3IgdGFnZ2luZyBhbiBlbWFp bCB3cml0dGVuCiAgICAgICAgICBpbiBHZXJtYW4sIHdoaWxlICJkZS1DSC0xOTk2IiBpcyBw cm9iYWJseSB1bm5lY2Vzc2FyaWx5CiAgICAgICAgICBwcmVjaXNlIGZvciBzdWNoIGEgdGFz ay4KCiAgIDIuICBUaGUgc2NyaXB0IHN1YnRhZyBTSE9VTEQgTk9UIGJlIHVzZWQgdG8gZm9y bSBsYW5ndWFnZSB0YWdzIHVubGVzcwogICAgICAgdGhlIHNjcmlwdCBhZGRzIHNvbWUgZGlz dGluZ3Vpc2hpbmcgaW5mb3JtYXRpb24gdG8gdGhlIHRhZy4gIFRoZQogICAgICAgZmllbGQg J1N1cHByZXNzLVNjcmlwdCcgaW4gdGhlIHByaW1hcnkgbGFuZ3VhZ2UgcmVjb3JkIGluIHRo ZQogICAgICAgcmVnaXN0cnkgaW5kaWNhdGVzIHdoaWNoIHNjcmlwdCBzdWJ0YWdzIGRvIG5v dCBhZGQgZGlzdGluZ3Vpc2hpbmcKICAgICAgIGluZm9ybWF0aW9uIGZvciBtb3N0IGFwcGxp Y2F0aW9ucy4KCiAgICAgICAqICBGb3IgZXhhbXBsZSwgdGhlIHN1YnRhZyAnTGF0bicgc2hv dWxkIG5vdCBiZSB1c2VkIHdpdGggdGhlCiAgICAgICAgICBwcmltYXJ5IGxhbmd1YWdlICdl bicgYmVjYXVzZSBuZWFybHkgYWxsIEVuZ2xpc2ggZG9jdW1lbnRzIGFyZQogICAgICAgICAg d3JpdHRlbiBpbiB0aGUgTGF0aW4gc2NyaXB0IGFuZCBpdCBhZGRzIG5vIGRpc3Rpbmd1aXNo aW5nCiAgICAgICAgICBpbmZvcm1hdGlvbi4gIEhvd2V2ZXIsIGlmIGEgZG9jdW1lbnQgd2Vy ZSB3cml0dGVuIGluIEVuZ2xpc2gKICAgICAgICAgIG1peGluZyBMYXRpbiBzY3JpcHQgd2l0 aCBhbm90aGVyIHNjcmlwdCBzdWNoIGFzIEJyYWlsbGUKICAgICAgICAgICgnQnJhaScpLCB0 aGVuIGl0IG1pZ2h0IGJlIGFwcHJvcHJpYXRlIHRvIGNob29zZSB0byBpbmRpY2F0ZQogICAg ICAgICAgYm90aCBzY3JpcHRzIHRvIGFpZCBpbiBjb250ZW50IHNlbGVjdGlvbiwgc3VjaCBh cyB0aGUKICAgICAgICAgIGFwcGxpY2F0aW9uIG9mIGEgc3R5bGUgc2hlZXQuCgogICAzLiAg SWYgYSB0YWcgb3Igc3VidGFnIGhhcyBhICdQcmVmZXJyZWQtVmFsdWUnIGZpZWxkIGluIGl0 cyByZWdpc3RyeQogICAgICAgZW50cnksIHRoZW4gdGhlIHZhbHVlIG9mIHRoYXQgZmllbGQg U0hPVUxEIGJlIHVzZWQgdG8gZm9ybSB0aGUKICAgICAgIGxhbmd1YWdlIHRhZyBpbiBwcmVm ZXJlbmNlIHRvIHRoZSB0YWcgb3Igc3VidGFnIGluIHdoaWNoIHRoZQogICAgICAgcHJlZmVy cmVkIHZhbHVlIGFwcGVhcnMuCgogICAgICAgKiAgRm9yIGV4YW1wbGUsIHVzZSAnaGUnIGZv ciBIZWJyZXcgaW4gcHJlZmVyZW5jZSB0byAnaXcnLgoKICAgNC4gIFRoZSAndW5kJyAoVW5k ZXRlcm1pbmVkKSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBTSE9VTEQgTk9UIGJlCiAgICAg ICB1c2VkIHRvIGxhYmVsIGNvbnRlbnQsIGV2ZW4gaWYgdGhlIGxhbmd1YWdlIGlzIHVua25v d24uICBPbWl0dGluZwogICAgICAgdGhlIGxhbmd1YWdlIHRhZyBhbHRvZ2V0aGVyIGlzIHBy ZWZlcnJlZCB0byB1c2luZyBhIHRhZyB3aXRoIGEKICAgICAgIHByaW1hcnkgbGFuZ3VhZ2Ug c3VidGFnIG9mICd1bmQnLiAgVGhlICd1bmQnIHN1YnRhZyBNQVkgYmUgdXNlZnVsCiAgICAg ICBmb3IgcHJvdG9jb2xzIHRoYXQgcmVxdWlyZSBhIGxhbmd1YWdlIHRhZyB0byBiZSBwcm92 aWRlZC4gIFRoZQogICAgICAgJ3VuZCcgc3VidGFnIE1BWSBhbHNvIGJlIHVzZWZ1bCB3aGVu IG1hdGNoaW5nIGxhbmd1YWdlIHRhZ3MgaW4KICAgICAgIGNlcnRhaW4gc2l0dWF0aW9ucy4K CiAgIDUuICBUaGUgJ211bCcgKE11bHRpcGxlKSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBT SE9VTEQgTk9UIGJlIHVzZWQKICAgICAgIHdoZW5ldmVyIHRoZSBwcm90b2NvbCBhbGxvd3Mg dGhlIHNlcGFyYXRlIHRhZ3MgZm9yIG11bHRpcGxlCiAgICAgICBsYW5ndWFnZXMsIGFzIGlz IHRoZSBjYXNlIGZvciB0aGUgQ29udGVudC1MYW5ndWFnZSBoZWFkZXIgaW4KICAgICAgIEhU VFAuICBUaGUgJ211bCcgc3VidGFnIGNvbnZleXMgbGl0dGxlIHVzZWZ1bCBpbmZvcm1hdGlv bjoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMTUsIDIwMDcg ICAgICAgICAgICAgICAgW1BhZ2UgMzldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg IGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA2CgoKICAgICAg IGNvbnRlbnQgaW4gbXVsdGlwbGUgbGFuZ3VhZ2VzIFNIT1VMRCBpbmRpdmlkdWFsbHkgdGFn IHRoZQogICAgICAgbGFuZ3VhZ2VzIHdoZXJlIHRoZXkgYXBwZWFyIG9yIG90aGVyd2lzZSBp bmRpY2F0ZSB0aGUgYWN0dWFsCiAgICAgICBsYW5ndWFnZSBpbiBwcmVmZXJlbmNlIHRvIHRo ZSAnbXVsJyBzdWJ0YWcuCgogICA2LiAgVGhlIHNhbWUgdmFyaWFudCBzdWJ0YWcgU0hPVUxE IE5PVCBiZSB1c2VkIG1vcmUgdGhhbiBvbmNlIHdpdGhpbgogICAgICAgYSBsYW5ndWFnZSB0 YWcuCgogICAgICAgKiAgRm9yIGV4YW1wbGUsIGRvIG5vdCB1c2UgImRlLURFLTE5MDEtMTkw MSIuCgogICBUbyBlbnN1cmUgY29uc2lzdGVudCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LCB0 aGlzIGRvY3VtZW50IGNvbnRhaW5zCiAgIHNldmVyYWwgcHJvdmlzaW9ucyB0byBhY2NvdW50 IGZvciBwb3RlbnRpYWwgaW5zdGFiaWxpdHkgaW4gdGhlCiAgIHN0YW5kYXJkcyB1c2VkIHRv IGRlZmluZSB0aGUgc3VidGFncyB0aGF0IG1ha2UgdXAgbGFuZ3VhZ2UgdGFncy4KICAgVGhl c2UgcHJvdmlzaW9ucyBtZWFuIHRoYXQgbm8gbGFuZ3VhZ2UgdGFnIGNyZWF0ZWQgdW5kZXIg dGhlIHJ1bGVzIGluCiAgIHRoaXMgZG9jdW1lbnQgd2lsbCBiZWNvbWUgb2Jzb2xldGUuCgo0 LjIuICBNZWFuaW5nIG9mIHRoZSBMYW5ndWFnZSBUYWcKCiAgIFRoZSByZWxhdGlvbnNoaXAg YmV0d2VlbiB0aGUgdGFnIGFuZCB0aGUgaW5mb3JtYXRpb24gaXQgcmVsYXRlcyB0byBpcwog ICBkZWZpbmVkIGJ5IHRoZSBjb250ZXh0IGluIHdoaWNoIHRoZSB0YWcgYXBwZWFycy4gIEFj Y29yZGluZ2x5LCB0aGlzCiAgIHNlY3Rpb24gZ2l2ZXMgb25seSBwb3NzaWJsZSBleGFtcGxl cyBvZiBpdHMgdXNhZ2UuCgogICBvICBGb3IgYSBzaW5nbGUgaW5mb3JtYXRpb24gb2JqZWN0 LCB0aGUgYXNzb2NpYXRlZCBsYW5ndWFnZSB0YWdzCiAgICAgIG1pZ2h0IGJlIGludGVycHJl dGVkIGFzIHRoZSBzZXQgb2YgbGFuZ3VhZ2VzIHRoYXQgaXMgbmVjZXNzYXJ5IGZvcgogICAg ICBhIGNvbXBsZXRlIGNvbXByZWhlbnNpb24gb2YgdGhlIGNvbXBsZXRlIG9iamVjdC4gIEV4 YW1wbGU6IFBsYWluCiAgICAgIHRleHQgZG9jdW1lbnRzLgoKICAgbyAgRm9yIGFuIGFnZ3Jl Z2F0aW9uIG9mIGluZm9ybWF0aW9uIG9iamVjdHMsIHRoZSBhc3NvY2lhdGVkIGxhbmd1YWdl CiAgICAgIHRhZ3MgY291bGQgYmUgdGFrZW4gYXMgdGhlIHNldCBvZiBsYW5ndWFnZXMgdXNl ZCBpbnNpZGUgY29tcG9uZW50cwogICAgICBvZiB0aGF0IGFnZ3JlZ2F0aW9uLiAgRXhhbXBs ZXM6IERvY3VtZW50IHN0b3JlcyBhbmQgbGlicmFyaWVzLgoKICAgbyAgRm9yIGluZm9ybWF0 aW9uIG9iamVjdHMgd2hvc2UgcHVycG9zZSBpcyB0byBwcm92aWRlIGFsdGVybmF0aXZlcywK ICAgICAgdGhlIGFzc29jaWF0ZWQgbGFuZ3VhZ2UgdGFncyBjb3VsZCBiZSByZWdhcmRlZCBh cyBhIGhpbnQgdGhhdCB0aGUKICAgICAgY29udGVudCBpcyBwcm92aWRlZCBpbiBzZXZlcmFs IGxhbmd1YWdlcyBhbmQgdGhhdCBvbmUgaGFzIHRvCiAgICAgIGluc3BlY3QgZWFjaCBvZiB0 aGUgYWx0ZXJuYXRpdmVzIGluIG9yZGVyIHRvIGZpbmQgaXRzIGxhbmd1YWdlIG9yCiAgICAg IGxhbmd1YWdlcy4gIEluIHRoaXMgY2FzZSwgdGhlIHByZXNlbmNlIG9mIG11bHRpcGxlIHRh Z3MgbWlnaHQgbm90CiAgICAgIG1lYW4gdGhhdCBvbmUgbmVlZHMgdG8gYmUgbXVsdGktbGlu Z3VhbCB0byBnZXQgY29tcGxldGUKICAgICAgdW5kZXJzdGFuZGluZyBvZiB0aGUgZG9jdW1l bnQuICBFeGFtcGxlOiBNSU1FIG11bHRpcGFydC8KICAgICAgYWx0ZXJuYXRpdmUuCgogICBv ICBJbiBtYXJrdXAgbGFuZ3VhZ2VzLCBzdWNoIGFzIEhUTUwgYW5kIFhNTCwgbGFuZ3VhZ2Ug aW5mb3JtYXRpb24KICAgICAgY2FuIGJlIGFkZGVkIHRvIGVhY2ggcGFydCBvZiB0aGUgZG9j dW1lbnQgaWRlbnRpZmllZCBieSB0aGUgbWFya3VwCiAgICAgIHN0cnVjdHVyZSAoaW5jbHVk aW5nIHRoZSB3aG9sZSBkb2N1bWVudCBpdHNlbGYpLiAgRm9yIGV4YW1wbGUsIG9uZQogICAg ICBjb3VsZCB3cml0ZSA8c3BhbiBsYW5nPSJmciI+Qydlc3QgbGEgdmllLjwvc3Bhbj4gaW5z aWRlIGEKICAgICAgTm9yd2VnaWFuIGRvY3VtZW50OyB0aGUgTm9yd2VnaWFuLXNwZWFraW5n IHVzZXIgY291bGQgdGhlbiBhY2Nlc3MKICAgICAgYSBGcmVuY2gtTm9yd2VnaWFuIGRpY3Rp b25hcnkgdG8gZmluZCBvdXQgd2hhdCB0aGUgbWFya2VkIHNlY3Rpb24KICAgICAgbWVhbnQu ICBJZiB0aGUgdXNlciB3ZXJlIGxpc3RlbmluZyB0byB0aGF0IGRvY3VtZW50IHRocm91Z2gg YQogICAgICBzcGVlY2ggc3ludGhlc2lzIGludGVyZmFjZSwgdGhpcyBmb3JtYXRpb24gY291 bGQgYmUgdXNlZCB0byBzaWduYWwKICAgICAgdGhlIHN5bnRoZXNpemVyIHRvIGFwcHJvcHJp YXRlbHkgYXBwbHkgRnJlbmNoIHRleHQtdG8tc3BlZWNoCgoKClBoaWxsaXBzICYgRGF2aXMg ICAgICAgICBFeHBpcmVzIE1hcmNoIDE1LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDQw XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICBTZXB0ZW1iZXIgMjAwNgoKCiAgICAgIHByb251bmNpYXRpb24gcnVsZXMgdG8g dGhhdCBzcGFuIG9mIHRleHQsIGluc3RlYWQgb2YgYXBwbHlpbmcgdGhlCiAgICAgIGluYXBw cm9wcmlhdGUgTm9yd2VnaWFuIHJ1bGVzLgoKICAgTGFuZ3VhZ2UgdGFncyBhcmUgcmVsYXRl ZCB3aGVuIHRoZXkgY29udGFpbiBhIHNpbWlsYXIgc2VxdWVuY2Ugb2YKICAgc3VidGFncy4g IEZvciBleGFtcGxlLCBpZiBhIGxhbmd1YWdlIHRhZyBCIGNvbnRhaW5zIGxhbmd1YWdlIHRh ZyBBIGFzCiAgIGEgcHJlZml4LCB0aGVuIEIgaXMgdHlwaWNhbGx5ICJuYXJyb3dlciIgb3Ig Im1vcmUgc3BlY2lmaWMiIHRoYW4gQS4KICAgVGh1cywgInpoLUhhbnQtVFciIGlzIG1vcmUg c3BlY2lmaWMgdGhhbiAiemgtSGFudCIuCgogICBUaGlzIHJlbGF0aW9uc2hpcCBpcyBub3Qg Z3VhcmFudGVlZCBpbiBhbGwgY2FzZXM6IHNwZWNpZmljYWxseSwKICAgbGFuZ3VhZ2VzIHRo YXQgYmVnaW4gd2l0aCB0aGUgc2FtZSBzZXF1ZW5jZSBvZiBzdWJ0YWdzIGFyZSBOT1QKICAg Z3VhcmFudGVlZCB0byBiZSBtdXR1YWxseSBpbnRlbGxpZ2libGUsIGFsdGhvdWdoIHRoZXkg bWlnaHQgYmUuICBGb3IKICAgZXhhbXBsZSwgdGhlIHRhZyAiYXoiIHNoYXJlcyBhIHByZWZp eCB3aXRoIGJvdGggImF6LUxhdG4iCiAgIChBemVyYmFpamFuaSB3cml0dGVuIHVzaW5nIHRo ZSBMYXRpbiBzY3JpcHQpIGFuZCAiYXotQ3lybCIKICAgKEF6ZXJiYWlqYW5pIHdyaXR0ZW4g dXNpbmcgdGhlIEN5cmlsbGljIHNjcmlwdCkuICBBIHBlcnNvbiBmbHVlbnQgaW4KICAgb25l IHNjcmlwdCBtaWdodCBub3QgYmUgYWJsZSB0byByZWFkIHRoZSBvdGhlciwgZXZlbiB0aG91 Z2ggdGhlIHRleHQKICAgbWlnaHQgYmUgaWRlbnRpY2FsLiAgQ29udGVudCB0YWdnZWQgYXMg ImF6IiBtb3N0IHByb2JhYmx5IGlzIHdyaXR0ZW4KICAgaW4ganVzdCBvbmUgc2NyaXB0IGFu ZCB0aHVzIG1pZ2h0IG5vdCBiZSBpbnRlbGxpZ2libGUgdG8gYSByZWFkZXIKICAgZmFtaWxp YXIgd2l0aCB0aGUgb3RoZXIgc2NyaXB0LgoKNC4zLiAgTGVuZ3RoIENvbnNpZGVyYXRpb25z CgogICBUaGVyZSBpcyBubyBkZWZpbmVkIHVwcGVyIGxpbWl0IG9uIHRoZSBzaXplIG9mIGxh bmd1YWdlIHRhZ3MuICBXaGlsZQogICBoaXN0b3JpY2FsbHkgbW9zdCBsYW5ndWFnZSB0YWdz IGhhdmUgY29uc2lzdGVkIG9mIGxhbmd1YWdlIGFuZCByZWdpb24KICAgc3VidGFncyB3aXRo IGEgY29tYmluZWQgdG90YWwgbGVuZ3RoIG9mIHVwIHRvIHNpeCBjaGFyYWN0ZXJzLCBsYXJn ZXIKICAgdGFncyBoYXZlIGFsd2F5cyBiZWVuIGJvdGggcG9zc2libGUgYW5kIGFjdHVhbGx5 IGFwcGVhcmVkIGluIHVzZS4KCiAgIE5laXRoZXIgdGhlIGxhbmd1YWdlIHRhZyBzeW50YXgg bm9yIG90aGVyIHJlcXVpcmVtZW50cyBpbiB0aGlzCiAgIGRvY3VtZW50IGltcG9zZSBhIGZp eGVkIHVwcGVyIGxpbWl0IG9uIHRoZSBudW1iZXIgb2Ygc3VidGFncyBpbiBhCiAgIGxhbmd1 YWdlIHRhZyAoYW5kIHRodXMgYW4gdXBwZXIgYm91bmQgb24gdGhlIHNpemUgb2YgYSB0YWcp LiAgVGhlCiAgIGxhbmd1YWdlIHRhZyBzeW50YXggc3VnZ2VzdHMgdGhhdCwgZGVwZW5kaW5n IG9uIHRoZSBzcGVjaWZpYwogICBsYW5ndWFnZSwgbW9yZSBzdWJ0YWdzIChhbmQgdGh1cyBh IGxvbmdlciB0YWcpIGFyZSBzb21ldGltZXMKICAgbmVjZXNzYXJ5IHRvIGNvbXBsZXRlbHkg aWRlbnRpZnkgdGhlIGxhbmd1YWdlIGZvciBjZXJ0YWluCiAgIGFwcGxpY2F0aW9uczsgdGh1 cywgaXQgaXMgcG9zc2libGUgdG8gZW52aXNpb24gbG9uZyBvciBjb21wbGV4IHN1YnRhZwog ICBzZXF1ZW5jZXMuCgo0LjMuMS4gIFdvcmtpbmcgd2l0aCBMaW1pdGVkIEJ1ZmZlciBTaXpl cwoKICAgU29tZSBhcHBsaWNhdGlvbnMgYW5kIHByb3RvY29scyBhcmUgZm9yY2VkIHRvIGFs bG9jYXRlIGZpeGVkIGJ1ZmZlcgogICBzaXplcyBvciBvdGhlcndpc2UgbGltaXQgdGhlIGxl bmd0aCBvZiBhIGxhbmd1YWdlIHRhZy4gIEEgY29uZm9ybWFudAogICBpbXBsZW1lbnRhdGlv biBvciBzcGVjaWZpY2F0aW9uIE1BWSByZWZ1c2UgdG8gc3VwcG9ydCB0aGUgc3RvcmFnZSBv ZgogICBsYW5ndWFnZSB0YWdzIHRoYXQgZXhjZWVkIGEgc3BlY2lmaWVkIGxlbmd0aC4gIEFu eSBzdWNoIGxpbWl0YXRpb24KICAgU0hPVUxEIGJlIGNsZWFybHkgZG9jdW1lbnRlZCwgYW5k IHN1Y2ggZG9jdW1lbnRhdGlvbiBTSE9VTEQgaW5jbHVkZQogICB3aGF0IGhhcHBlbnMgdG8g bG9uZ2VyIHRhZ3MgKGZvciBleGFtcGxlLCB3aGV0aGVyIGFuIGVycm9yIHZhbHVlIGlzCiAg IGdlbmVyYXRlZCBvciB0aGUgbGFuZ3VhZ2UgdGFnIGlzIHRydW5jYXRlZCkuICBBIHByb3Rv Y29sIHRoYXQgYWxsb3dzCiAgIHRhZ3MgdG8gYmUgdHJ1bmNhdGVkIGF0IGFuIGFyYml0cmFy eSBsaW1pdCwgd2l0aG91dCBnaXZpbmcgYW55CiAgIGluZGljYXRpb24gb2Ygd2hhdCB0aGF0 IGxpbWl0IGlzLCBoYXMgdGhlIHBvdGVudGlhbCBmb3IgY2F1c2luZyBoYXJtCiAgIGJ5IGNo YW5naW5nIHRoZSBtZWFuaW5nIG9mIHRhZ3MgaW4gc3Vic3RhbnRpYWwgd2F5cy4KCgoKClBo aWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDE1LCAyMDA3ICAgICAgICAg ICAgICAgIFtQYWdlIDQxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFn cy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNgoKCiAgIEluIHByYWN0aWNl LCBtb3N0IGxhbmd1YWdlIHRhZ3MgZG8gbm90IHJlcXVpcmUgbW9yZSB0aGFuIGEgZmV3CiAg IHN1YnRhZ3MgYW5kIHdpbGwgbm90IGFwcHJvYWNoIHJlYXNvbmFibHkgc2l6ZWQgYnVmZmVy IGxpbWl0YXRpb25zOwogICBzZWUgU2VjdGlvbiA0LjEuCgogICBTb21lIHNwZWNpZmljYXRp b25zIG9yIHByb3RvY29scyBoYXZlIGxpbWl0cyBvbiB0YWcgbGVuZ3RoIGJ1dCBkbyBub3QK ICAgaGF2ZSBhIGZpeGVkIGxlbmd0aCBsaW1pdGF0aW9uLiAgRm9yIGV4YW1wbGUsIFtSRkMy MjMxXSBoYXMgbm8KICAgZXhwbGljaXQgbGVuZ3RoIGxpbWl0YXRpb246IHRoZSBsZW5ndGgg YXZhaWxhYmxlIGZvciB0aGUgbGFuZ3VhZ2UgdGFnCiAgIGlzIGNvbnN0cmFpbmVkIGJ5IHRo ZSBsZW5ndGggb2Ygb3RoZXIgaGVhZGVyIGNvbXBvbmVudHMgKHN1Y2ggYXMgdGhlCiAgIGNo YXJzZXQncyBuYW1lKSBjb3VwbGVkIHdpdGggdGhlIDc2LWNoYXJhY3RlciBsaW1pdCBpbiBb UkZDMjA0N10uCiAgIFRodXMsIHRoZSAibGltaXQiIG1pZ2h0IGJlIDUwIG9yIG1vcmUgY2hh cmFjdGVycywgYnV0IGl0IGNvdWxkCiAgIHBvdGVudGlhbGx5IGJlIHF1aXRlIHNtYWxsLgoK ICAgVGhlIGNvbnNpZGVyYXRpb25zIGZvciBhc3NpZ25pbmcgYSBidWZmZXIgbGltaXQgYXJl OgoKICAgICAgSW1wbGVtZW50YXRpb25zIFNIT1VMRCBOT1QgdHJ1bmNhdGUgbGFuZ3VhZ2Ug dGFncyB1bmxlc3MgdGhlCiAgICAgIG1lYW5pbmcgb2YgdGhlIHRhZyBpcyBwdXJwb3NlZnVs bHkgYmVpbmcgY2hhbmdlZCwgb3IgdW5sZXNzIHRoZQogICAgICB0YWcgZG9lcyBub3QgZml0 IGludG8gYSBsaW1pdGVkIGJ1ZmZlciBzaXplIHNwZWNpZmllZCBieSBhCiAgICAgIHByb3Rv Y29sIGZvciBzdG9yYWdlIG9yIHRyYW5zbWlzc2lvbi4KCiAgICAgIEltcGxlbWVudGF0aW9u cyBTSE9VTEQgd2FybiB0aGUgdXNlciB3aGVuIGEgdGFnIGlzIHRydW5jYXRlZCBzaW5jZQog ICAgICB0cnVuY2F0aW9uIGNoYW5nZXMgdGhlIHNlbWFudGljIG1lYW5pbmcgb2YgdGhlIHRh Zy4KCiAgICAgIEltcGxlbWVudGF0aW9ucyBvZiBwcm90b2NvbHMgb3Igc3BlY2lmaWNhdGlv bnMgdGhhdCBhcmUgc3BhY2UKICAgICAgY29uc3RyYWluZWQgYnV0IGRvIG5vdCBoYXZlIGEg Zml4ZWQgbGltaXQgU0hPVUxEIHVzZSB0aGUgbG9uZ2VzdAogICAgICBwb3NzaWJsZSB0YWcg aW4gcHJlZmVyZW5jZSB0byB0cnVuY2F0aW9uLgoKICAgICAgUHJvdG9jb2xzIG9yIHNwZWNp ZmljYXRpb25zIHRoYXQgc3BlY2lmeSBsaW1pdGVkIGJ1ZmZlciBzaXplcyBmb3IKICAgICAg bGFuZ3VhZ2UgdGFncyBNVVNUIGFsbG93IGZvciBsYW5ndWFnZSB0YWdzIG9mIHVwIHRvIDMz IGNoYXJhY3RlcnMuCgogICAgICBQcm90b2NvbHMgb3Igc3BlY2lmaWNhdGlvbnMgdGhhdCBz cGVjaWZ5IGxpbWl0ZWQgYnVmZmVyIHNpemVzIGZvcgogICAgICBsYW5ndWFnZSB0YWdzIFNI T1VMRCBhbGxvdyBmb3IgbGFuZ3VhZ2UgdGFncyBvZiBhdCBsZWFzdCA0MgogICAgICBjaGFy YWN0ZXJzLgoKICAgVGhlIGZvbGxvd2luZyBpbGx1c3RyYXRpb24gc2hvd3MgaG93IHRoZSA0 Mi1jaGFyYWN0ZXIgcmVjb21tZW5kYXRpb24KICAgd2FzIGRlcml2ZWQuICBUaGUgY29tYmlu YXRpb24gb2YgbGFuZ3VhZ2UgYW5kIGV4dGVuZGVkIGxhbmd1YWdlCiAgIHN1YnRhZ3Mgd2Fz IGNob3NlbiBmb3IgZnV0dXJlIGNvbXBhdGliaWxpdHkuICBBdCB1cCB0byAxNSBjaGFyYWN0 ZXJzLAogICB0aGlzIGNvbWJpbmF0aW9uIGlzIGxvbmdlciB0aGFuIHRoZSBsb25nZXN0IHBv c3NpYmxlIHByaW1hcnkgbGFuZ3VhZ2UKICAgc3VidGFnICg4IGNoYXJhY3RlcnMpOgoKCgoK CgoKCgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMTUsIDIw MDcgICAgICAgICAgICAgICAgW1BhZ2UgNDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA2CgoKICAg bGFuZ3VhZ2UgICAgICA9ICAzIChJU08gNjM5LTI7IElTTyA2MzktMSByZXF1aXJlcyAyKQog ICBleHRsYW5nMSAgICAgID0gIDQgKGVhY2ggc3Vic2VxdWVudCBzdWJ0YWcgaW5jbHVkZXMg Jy0nKQogICBleHRsYW5nMiAgICAgID0gIDQgKHVubGlrZWx5OiBuZWVkcyBwcmVmaXg9Imxh bmd1YWdlLWV4dGxhbmcxIikKICAgZXh0bGFuZzMgICAgICA9ICA0IChleHRyZW1lbHkgdW5s aWtlbHkpCiAgIHNjcmlwdCAgICAgICAgPSAgNSAoaWYgbm90IHN1cHByZXNzZWQ6IHNlZSBT ZWN0aW9uIDQuMSkKICAgcmVnaW9uICAgICAgICA9ICA0IChVTiBNLjQ5OyBJU08gMzE2NiBy ZXF1aXJlcyAzKQogICB2YXJpYW50MSAgICAgID0gIDkgKE1VU1QgaGF2ZSBsYW5ndWFnZSBh cyBhIHByZWZpeCkKICAgdmFyaWFudDIgICAgICA9ICA5IChNVVNUIGhhdmUgbGFuZ3VhZ2Ut dmFyaWFudDEgYXMgYSBwcmVmaXgpCgogICB0b3RhbCAgICAgICAgID0gNDIgY2hhcmFjdGVy cwoKICAgRmlndXJlIDc6IERlcml2YXRpb24gb2YgdGhlIExpbWl0IG9uIFRhZyBMZW5ndGgK CjQuMy4yLiAgVHJ1bmNhdGlvbiBvZiBMYW5ndWFnZSBUYWdzCgogICBUcnVuY2F0aW9uIG9m IGEgbGFuZ3VhZ2UgdGFnIGFsdGVycyB0aGUgbWVhbmluZyBvZiB0aGUgdGFnLCBhbmQgdGh1 cwogICBTSE9VTEQgYmUgYXZvaWRlZC4gIEhvd2V2ZXIsIHRydW5jYXRpb24gb2YgbGFuZ3Vh Z2UgdGFncyBpcyBzb21ldGltZXMKICAgbmVjZXNzYXJ5IGR1ZSB0byBsaW1pdGVkIGJ1ZmZl ciBzaXplcy4gIFN1Y2ggdHJ1bmNhdGlvbiBNVVNUIE5PVAogICBwZXJtaXQgYSBzdWJ0YWcg dG8gYmUgY2hvcHBlZCBvZmYgaW4gdGhlIG1pZGRsZSBvciB0aGUgZm9ybWF0aW9uIG9mCiAg IGludmFsaWQgdGFncyAoZm9yIGV4YW1wbGUsIG9uZSBlbmRpbmcgd2l0aCB0aGUgIi0iIGNo YXJhY3RlcikuCgogICBUaGlzIG1lYW5zIHRoYXQgYXBwbGljYXRpb25zIG9yIHByb3RvY29s cyB0aGF0IHRydW5jYXRlIHRhZ3MgTVVTVCBkbwogICBzbyBieSBwcm9ncmVzc2l2ZWx5IHJl bW92aW5nIHN1YnRhZ3MgYWxvbmcgd2l0aCB0aGVpciBwcmVjZWRpbmcgIi0iCiAgIGZyb20g dGhlIHJpZ2h0IHNpZGUgb2YgdGhlIGxhbmd1YWdlIHRhZyB1bnRpbCB0aGUgdGFnIGlzIHNo b3J0IGVub3VnaAogICBmb3IgdGhlIGdpdmVuIGJ1ZmZlci4gIElmIHRoZSByZXN1bHRpbmcg dGFnIGVuZHMgd2l0aCBhIHNpbmdsZS0KICAgY2hhcmFjdGVyIHN1YnRhZywgdGhhdCBzdWJ0 YWcgYW5kIGl0cyBwcmVjZWRpbmcgIi0iIE1VU1QgYWxzbyBiZQogICByZW1vdmVkLiAgRm9y IGV4YW1wbGU6CgogICBUYWcgdG8gdHJ1bmNhdGU6IHpoLUxhdG4tQ04tdmFyaWFudDEtYS1l eHRlbmQxLXgtd2FkZWdpbGUtcHJpdmF0ZTEKICAgMS4gemgtTGF0bi1DTi12YXJpYW50MS1h LWV4dGVuZDEteC13YWRlZ2lsZQogICAyLiB6aC1MYXRuLUNOLXZhcmlhbnQxLWEtZXh0ZW5k MQogICAzLiB6aC1MYXRuLUNOLXZhcmlhbnQxCiAgIDQuIHpoLUxhdG4tQ04KICAgNS4gemgt TGF0bgogICA2LiB6aAoKICAgRmlndXJlIDg6IEV4YW1wbGUgb2YgVGFnIFRydW5jYXRpb24K CjQuNC4gIENhbm9uaWNhbGl6YXRpb24gb2YgTGFuZ3VhZ2UgVGFncwoKICAgU2luY2UgYSBw YXJ0aWN1bGFyIGxhbmd1YWdlIHRhZyBpcyBzb21ldGltZXMgdXNlZCBieSBtYW55IHByb2Nl c3NlcywKICAgbGFuZ3VhZ2UgdGFncyBTSE9VTEQgYWx3YXlzIGJlIGNyZWF0ZWQgb3IgZ2Vu ZXJhdGVkIGluIGEgY2Fub25pY2FsCiAgIGZvcm0uCgogICBBIGxhbmd1YWdlIHRhZyBpcyBp biBjYW5vbmljYWwgZm9ybSB3aGVuOgoKICAgMS4gIFRoZSB0YWcgaXMgd2VsbC1mb3JtZWQg YWNjb3JkaW5nIHRoZSBydWxlcyBpbiBTZWN0aW9uIDIuMSBhbmQKICAgICAgIFNlY3Rpb24g Mi4yLgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAxNSwgMjAw NyAgICAgICAgICAgICAgICBbUGFnZSA0M10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDYKCgogICAy LiAgU3VidGFncyBvZiB0eXBlICdSZWdpb24nIHRoYXQgaGF2ZSBhIFByZWZlcnJlZC1WYWx1 ZSBtYXBwaW5nIGluCiAgICAgICB0aGUgSUFOQSByZWdpc3RyeSAoc2VlIFNlY3Rpb24gMy4x KSBTSE9VTEQgYmUgcmVwbGFjZWQgd2l0aCB0aGVpcgogICAgICAgbWFwcGVkIHZhbHVlLiAg Tm90ZTogSW4gcmFyZSBjYXNlcywgdGhlIG1hcHBlZCB2YWx1ZSB3aWxsIGFsc28KICAgICAg IGhhdmUgYSBQcmVmZXJyZWQtVmFsdWUuCgogICAzLiAgUmVkdW5kYW50IG9yIGdyYW5kZmF0 aGVyZWQgdGFncyB0aGF0IGhhdmUgYSBQcmVmZXJyZWQtVmFsdWUKICAgICAgIG1hcHBpbmcg aW4gdGhlIElBTkEgcmVnaXN0cnkgKHNlZSBTZWN0aW9uIDMuMSkgTVVTVCBiZSByZXBsYWNl ZAogICAgICAgd2l0aCB0aGVpciBtYXBwZWQgdmFsdWUuICBUaGVzZSBpdGVtcyBlaXRoZXIg YXJlIGRlcHJlY2F0ZWQKICAgICAgIG1hcHBpbmdzIGNyZWF0ZWQgYmVmb3JlIHRoZSBhZG9w dGlvbiBvZiB0aGlzIGRvY3VtZW50IChzdWNoIGFzCiAgICAgICB0aGUgbWFwcGluZyBvZiAi bm8tbnluIiB0byAibm4iIG9yICJpLWtsaW5nb24iIHRvICJ0bGgiKSBvciBhcmUKICAgICAg IHRoZSByZXN1bHQgb2YgbGF0ZXIgcmVnaXN0cmF0aW9ucyBvciBhZGRpdGlvbnMgdG8gdGhp cyBkb2N1bWVudAogICAgICAgKGZvciBleGFtcGxlLCAiemgtZ3VveXUiIG1pZ2h0IGJlIG1h cHBlZCB0byBhIGxhbmd1YWdlLWV4dGxhbmcKICAgICAgIGNvbWJpbmF0aW9uIHN1Y2ggYXMg InpoLWNtbiIgYnkgc29tZSBmdXR1cmUgdXBkYXRlIG9mIHRoaXMKICAgICAgIGRvY3VtZW50 KS4KCiAgIDQuICBPdGhlciBzdWJ0YWdzIHRoYXQgaGF2ZSBhIFByZWZlcnJlZC1WYWx1ZSBt YXBwaW5nIGluIHRoZSBJQU5BCiAgICAgICByZWdpc3RyeSAoc2VlIFNlY3Rpb24gMy4xKSBN VVNUIGJlIHJlcGxhY2VkIHdpdGggdGhlaXIgbWFwcGVkCiAgICAgICB2YWx1ZS4gIFRoZXNl IGl0ZW1zIGNvbnNpc3QgZW50aXJlbHkgb2YgY2xlcmljYWwgY29ycmVjdGlvbnMgdG8KICAg ICAgIElTTyA2MzktMSBpbiB3aGljaCB0aGUgZGVwcmVjYXRlZCBzdWJ0YWdzIGhhdmUgYmVl biBtYWludGFpbmVkCiAgICAgICBmb3IgY29tcGF0aWJpbGl0eSBwdXJwb3Nlcy4KCiAgIDUu ICBJZiBtb3JlIHRoYW4gb25lIGV4dGVuc2lvbiBzdWJ0YWcgc2VxdWVuY2UgZXhpc3RzLCB0 aGUgZXh0ZW5zaW9uCiAgICAgICBzZXF1ZW5jZXMgYXJlIG9yZGVyZWQgaW50byBjYXNlLWlu c2Vuc2l0aXZlIEFTQ0lJIG9yZGVyIGJ5CiAgICAgICBzaW5nbGV0b24gc3VidGFnLgoKICAg RXhhbXBsZTogVGhlIGxhbmd1YWdlIHRhZyAiZW4tQS1hYWEtQi1jY2MtYmJiLXgteHl6IiBp cyBpbiBjYW5vbmljYWwKICAgZm9ybSwgd2hpbGUgImVuLUItY2NjLWJiYi1BLWFhYS1YLXh5 eiIgaXMgd2VsbC1mb3JtZWQgYnV0IG5vdCBpbgogICBjYW5vbmljYWwgZm9ybS4KCiAgIEV4 YW1wbGU6IFRoZSBsYW5ndWFnZSB0YWcgImVuLUJVIiAoRW5nbGlzaCBhcyB1c2VkIGluIEJ1 cm1hKSBpcyBub3QKICAgY2Fub25pY2FsIGJlY2F1c2UgdGhlICdCVScgc3VidGFnIGhhcyBh IGNhbm9uaWNhbCBtYXBwaW5nIHRvICdNTScKICAgKE15YW5tYXIpLCBhbHRob3VnaCB0aGUg dGFnICJlbi1CVSIgbWFpbnRhaW5zIGl0cyB2YWxpZGl0eS4KCiAgIENhbm9uaWNhbGl6YXRp b24gb2YgbGFuZ3VhZ2UgdGFncyBkb2VzIG5vdCBpbXBseSBhbnl0aGluZyBhYm91dCB0aGUK ICAgdXNlIG9mIHVwcGVyIG9yIGxvd2VyY2FzZSBsZXR0ZXJzIHdoZW4gcHJvY2Vzc2luZyBv ciBjb21wYXJpbmcKICAgc3VidGFncyAoYW5kIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIu MSkuICBBbGwgY29tcGFyaXNvbnMgTVVTVCBiZQogICBwZXJmb3JtZWQgaW4gYSBjYXNlLWlu c2Vuc2l0aXZlIG1hbm5lci4KCiAgIFdoZW4gcGVyZm9ybWluZyBjYW5vbmljYWxpemF0aW9u IG9mIGxhbmd1YWdlIHRhZ3MsIHByb2Nlc3NvcnMgTUFZCiAgIHJlZ3VsYXJpemUgdGhlIGNh c2Ugb2YgdGhlIHN1YnRhZ3MgKHRoYXQgaXMsIHRoaXMgcHJvY2VzcyBpcwogICBPUFRJT05B TCksIGZvbGxvd2luZyB0aGUgY2FzZSB1c2VkIGluIHRoZSByZWdpc3RyeS4gIE5vdGUgdGhh dCB0aGlzCiAgIGNvcnJlc3BvbmRzIHRvIHRoZSBmb2xsb3dpbmcgY2FzaW5nIHJ1bGVzOiB1 cHBlcmNhc2UgYWxsIG5vbi1pbml0aWFsCiAgIHR3by1sZXR0ZXIgc3VidGFnczsgdGl0bGVj YXNlIGFsbCBub24taW5pdGlhbCBmb3VyLWxldHRlciBzdWJ0YWdzOwogICBsb3dlcmNhc2Ug ZXZlcnl0aGluZyBlbHNlLgoKICAgTm90ZTogQ2FzZSBmb2xkaW5nIG9mIEFTQ0lJIGxldHRl cnMgaW4gY2VydGFpbiBsb2NhbGVzLCB1bmxlc3MKICAgY2FyZWZ1bGx5IGhhbmRsZWQsIHNv bWV0aW1lcyBwcm9kdWNlcyBub24tQVNDSUkgY2hhcmFjdGVyIHZhbHVlcy4KICAgVGhlIFVu aWNvZGUgQ2hhcmFjdGVyIERhdGFiYXNlIGZpbGUgIlNwZWNpYWxDYXNpbmcudHh0IiBkZWZp bmVzIHRoZQoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAxNSwg MjAwNyAgICAgICAgICAgICAgICBbUGFnZSA0NF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDYKCgog ICBzcGVjaWZpYyBjYXNlcyB0aGF0IGFyZSBrbm93biB0byBjYXVzZSBwcm9ibGVtcyB3aXRo IHRoaXMuICBJbgogICBwYXJ0aWN1bGFyLCB0aGUgbGV0dGVyICdpJyAoVSswMDY5KSBpbiBU dXJraXNoIGFuZCBBemVyYmFpamFuaSBpcwogICB1cHBlcmNhc2VkIHRvIFUrMDEzMCAoTEFU SU4gQ0FQSVRBTCBMRVRURVIgSSBXSVRIIERPVCBBQk9WRSkuCiAgIEltcGxlbWVudGVycyBT SE9VTEQgc3BlY2lmeSBhIGxvY2FsZS1uZXV0cmFsIGNhc2luZyBvcGVyYXRpb24gdG8KICAg ZW5zdXJlIHRoYXQgY2FzZSBmb2xkaW5nIG9mIHN1YnRhZ3MgZG9lcyBub3QgcHJvZHVjZSB0 aGlzIHZhbHVlLAogICB3aGljaCBpcyBpbGxlZ2FsIGluIGxhbmd1YWdlIHRhZ3MuICBGb3Ig ZXhhbXBsZSwgaWYgb25lIHdlcmUgdG8KICAgdXBwZXJjYXNlIHRoZSByZWdpb24gc3VidGFn ICdpbicgdXNpbmcgVHVya2lzaCBsb2NhbGUgcnVsZXMsIHRoZQogICBzZXF1ZW5jZSBVKzAx MzAgVSswMDRFIHdvdWxkIHJlc3VsdCBpbnN0ZWFkIG9mIHRoZSBleHBlY3RlZCAnSU4nLgoK ICAgTm90ZTogaWYgdGhlIGZpZWxkICdEZXByZWNhdGVkJyBhcHBlYXJzIGluIGEgcmVnaXN0 cnkgcmVjb3JkIHdpdGhvdXQKICAgYW4gYWNjb21wYW55aW5nICdQcmVmZXJyZWQtVmFsdWUn IGZpZWxkLCB0aGVuIHRoYXQgdGFnIG9yIHN1YnRhZyBpcwogICBkZXByZWNhdGVkIHdpdGhv dXQgYSByZXBsYWNlbWVudC4gIFZhbGlkYXRpbmcgcHJvY2Vzc29ycyBTSE9VTEQgTk9UCiAg IGdlbmVyYXRlIHRhZ3MgdGhhdCBpbmNsdWRlIHRoZXNlIHZhbHVlcywgYWx0aG91Z2ggdGhl IHZhbHVlcyBhcmUKICAgY2Fub25pY2FsIHdoZW4gdGhleSBhcHBlYXIgaW4gYSBsYW5ndWFn ZSB0YWcuCgogICBBbiBleHRlbnNpb24gTVVTVCBkZWZpbmUgYW55IHJlbGF0aW9uc2hpcHMg dGhhdCBleGlzdCBiZXR3ZWVuIHRoZQogICB2YXJpb3VzIHN1YnRhZ3MgaW4gdGhlIGV4dGVu c2lvbiBhbmQgdGh1cyBNQVkgZGVmaW5lIGFuIGFsdGVybmF0ZQogICBjYW5vbmljYWxpemF0 aW9uIHNjaGVtZSBmb3IgdGhlIGV4dGVuc2lvbidzIHN1YnRhZ3MuICBFeHRlbnNpb25zIE1B WQogICBkZWZpbmUgaG93IHRoZSBvcmRlciBvZiB0aGUgZXh0ZW5zaW9uJ3Mgc3VidGFncyBh cmUgaW50ZXJwcmV0ZWQuICBGb3IKICAgZXhhbXBsZSwgYW4gZXh0ZW5zaW9uIGNvdWxkIGRl ZmluZSB0aGF0IGl0cyBzdWJ0YWdzIGFyZSBpbiBjYW5vbmljYWwKICAgb3JkZXIgd2hlbiB0 aGUgc3VidGFncyBhcmUgcGxhY2VkIGludG8gQVNDSUkgb3JkZXI6IHRoYXQgaXMsICJlbi1h LQogICBhYWEtYmJiLWNjYyIgaW5zdGVhZCBvZiAiZW4tYS1jY2MtYmJiLWFhYSIuICBBbm90 aGVyIGV4dGVuc2lvbiBtaWdodAogICBkZWZpbmUgdGhhdCB0aGUgb3JkZXIgb2YgdGhlIHN1 YnRhZ3MgaW5mbHVlbmNlcyB0aGVpciBzZW1hbnRpYwogICBtZWFuaW5nIChzbyB0aGF0ICJl bi1iLWNjYy1iYmItYWFhIiBoYXMgYSBkaWZmZXJlbnQgdmFsdWUgZnJvbSAiZW4tYi0KICAg YWFhLWJiYi1jY2MiKS4gIEhvd2V2ZXIsIGV4dGVuc2lvbiBzcGVjaWZpY2F0aW9ucyBTSE9V TEQgYmUgZGVzaWduZWQKICAgc28gdGhhdCB0aGV5IGFyZSB0b2xlcmFudCBvZiB0aGUgdHlw aWNhbCBwcm9jZXNzZXMgZGVzY3JpYmVkIGluCiAgIFNlY3Rpb24gMy43LgoKNC41LiAgQ29u c2lkZXJhdGlvbnMgZm9yIFByaXZhdGUgVXNlIFN1YnRhZ3MKCiAgIFByaXZhdGUgdXNlIHN1 YnRhZ3MsIGxpa2UgYWxsIG90aGVyIHN1YnRhZ3MsIE1VU1QgY29uZm9ybSB0byB0aGUKICAg Zm9ybWF0IGFuZCBjb250ZW50IGNvbnN0cmFpbnRzIGluIHRoZSBBQk5GLiAgUHJpdmF0ZSB1 c2Ugc3VidGFncyBoYXZlCiAgIG5vIG1lYW5pbmcgb3V0c2lkZSB0aGUgcHJpdmF0ZSBhZ3Jl ZW1lbnQgYmV0d2VlbiB0aGUgcGFydGllcyB0aGF0CiAgIGludGVuZCB0byB1c2Ugb3IgZXhj aGFuZ2UgbGFuZ3VhZ2UgdGFncyB0aGF0IGVtcGxveSB0aGVtLiAgVGhlIHNhbWUKICAgc3Vi dGFncyBNQVkgYmUgdXNlZCB3aXRoIGEgZGlmZmVyZW50IG1lYW5pbmcgdW5kZXIgYSBzZXBh cmF0ZSBwcml2YXRlCiAgIGFncmVlbWVudC4gIFRoZXkgU0hPVUxEIE5PVCBiZSB1c2VkIHdo ZXJlIGFsdGVybmF0aXZlcyBleGlzdCBhbmQKICAgU0hPVUxEIE5PVCBiZSB1c2VkIGluIGNv bnRlbnQgb3IgcHJvdG9jb2xzIGludGVuZGVkIGZvciBnZW5lcmFsIHVzZS4KCiAgIFByaXZh dGUgdXNlIHN1YnRhZ3MgYXJlIHNpbXBseSB1c2VsZXNzIGZvciBpbmZvcm1hdGlvbiBleGNo YW5nZQogICB3aXRob3V0IHByaW9yIGFycmFuZ2VtZW50LiAgVGhlIHZhbHVlIGFuZCBzZW1h bnRpYyBtZWFuaW5nIG9mIHByaXZhdGUKICAgdXNlIHRhZ3MgYW5kIG9mIHRoZSBzdWJ0YWdz IHVzZWQgd2l0aGluIHN1Y2ggYSBsYW5ndWFnZSB0YWcgYXJlIG5vdAogICBkZWZpbmVkIGJ5 IHRoaXMgZG9jdW1lbnQuCgogICBTdWJ0YWdzIGRlZmluZWQgaW4gdGhlIElBTkEgcmVnaXN0 cnkgYXMgaGF2aW5nIGEgc3BlY2lmaWMgcHJpdmF0ZSB1c2UKICAgbWVhbmluZyBjb252ZXkg bW9yZSBpbmZvcm1hdGlvbiB0aGF0IGEgcHVyZWx5IHByaXZhdGUgdXNlIHRhZwogICBwcmVm aXhlZCBieSB0aGUgc2luZ2xldG9uIHN1YnRhZyAneCcuICBGb3IgYXBwbGljYXRpb25zLCB0 aGlzCiAgIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gTUFZIGJlIHVzZWZ1bC4KCgoKClBoaWxs aXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDE1LCAyMDA3ICAgICAgICAgICAg ICAgIFtQYWdlIDQ1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1y ZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNgoKCiAgIEZvciBleGFtcGxlLCB0 aGUgcmVnaW9uIHN1YnRhZ3MgJ0FBJywgJ1paJywgYW5kIGluIHRoZSByYW5nZXMKICAgJ1FN Jy0nUVonIGFuZCAnWEEnLSdYWicgKGRlcml2ZWQgZnJvbSBJU08gMzE2NiBwcml2YXRlIHVz ZSBjb2RlcykgTUFZCiAgIGJlIHVzZWQgdG8gZm9ybSBhIGxhbmd1YWdlIHRhZy4gIEEgdGFn IHN1Y2ggYXMgInpoLUhhbnMtWFEiIGNvbnZleXMgYQogICBncmVhdCBkZWFsIG9mIHB1Ymxp YywgaW50ZXJjaGFuZ2VhYmxlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBsYW5ndWFnZQogICBt YXRlcmlhbCAodGhhdCBpdCBpcyBDaGluZXNlIGluIHRoZSBzaW1wbGlmaWVkIENoaW5lc2Ug c2NyaXB0IGFuZCBpcwogICBzdWl0YWJsZSBmb3Igc29tZSBnZW9ncmFwaGljIHJlZ2lvbiAn WFEnKS4gIFdoaWxlIHRoZSBwcmVjaXNlCiAgIGdlb2dyYXBoaWMgcmVnaW9uIGlzIG5vdCBr bm93biBvdXRzaWRlIG9mIHByaXZhdGUgYWdyZWVtZW50LCB0aGUgdGFnCiAgIGNvbnZleXMg ZmFyIG1vcmUgaW5mb3JtYXRpb24gdGhhbiBhbiBvcGFxdWUgdGFnIHN1Y2ggYXMgIngtc29t ZUxhbmciLAogICB3aGljaCBjb250YWlucyBubyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbGFu Z3VhZ2Ugc3VidGFnIG9yIHNjcmlwdAogICBzdWJ0YWcgb3V0c2lkZSBvZiB0aGUgcHJpdmF0 ZSBhZ3JlZW1lbnQuCgogICBIb3dldmVyLCBpbiBzb21lIGNhc2VzIGNvbnRlbnQgdGFnZ2Vk IHdpdGggcHJpdmF0ZSB1c2Ugc3VidGFncyBNQVkKICAgaW50ZXJhY3Qgd2l0aCBvdGhlciBz eXN0ZW1zIGluIGEgZGlmZmVyZW50IGFuZCBwb3NzaWJseSB1bnN1aXRhYmxlCiAgIG1hbm5l ciBjb21wYXJlZCB0byB0YWdzIHRoYXQgdXNlIG9wYXF1ZSwgcHJpdmF0ZWx5IGRlZmluZWQg c3VidGFncywKICAgc28gdGhlIGNob2ljZSBvZiB0aGUgYmVzdCBhcHByb2FjaCBzb21ldGlt ZXMgZGVwZW5kcyBvbiB0aGUKICAgcGFydGljdWxhciBkb21haW4gaW4gcXVlc3Rpb24uCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgIEV4cGlyZXMgTWFyY2ggMTUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgNDZdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAg ICAgIFNlcHRlbWJlciAyMDA2CgoKNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMg c2VjdGlvbiBkZWFscyB3aXRoIHRoZSBwcm9jZXNzZXMgYW5kIHJlcXVpcmVtZW50cyBuZWNl c3NhcnkgZm9yCiAgIElBTkEgdG8gdW5kZXJ0YWtlIHRvIG1haW50YWluIHRoZSBzdWJ0YWcg YW5kIGV4dGVuc2lvbiByZWdpc3RyaWVzIGFzCiAgIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVu dCBhbmQgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSByZXF1aXJlbWVudHMgb2YKICAgW1JGQzI0 MzRdLgoKICAgVGhlIGltcGFjdCBvbiB0aGUgSUFOQSBtYWludGFpbmVycyBvZiB0aGUgdHdv IHJlZ2lzdHJpZXMgZGVmaW5lZCBieQogICB0aGlzIGRvY3VtZW50IHdpbGwgYmUgYSBzbWFs bCBpbmNyZWFzZSBpbiB0aGUgZnJlcXVlbmN5IG9mIG5ldwogICBlbnRyaWVzIG9yIHVwZGF0 ZXMuCgo1LjEuICBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkKCiAgIFVwb24gYWRvcHRpb24g b2YgdGhpcyBkb2N1bWVudCwgSUFOQSBTSEFMTCB1cGRhdGUgdGhlIHJlZ2lzdHJ5IHVzaW5n CiAgIGluc3RydWN0aW9ucyBhbmQgY29udGVudCBwcm92aWRlZCBpbiBhIGNvbXBhbmlvbiBk b2N1bWVudDogW2luaXRpYWwtCiAgIHJlZ2lzdHJ5XS4gIFRoZSBjcml0ZXJpYSBhbmQgcHJv Y2VzcyBmb3Igc2VsZWN0aW5nIHRoZSB1cGRhdGVkIHNldCBvZgogICByZWNvcmRzIGFyZSBk ZXNjcmliZWQgaW4gdGhhdCBkb2N1bWVudC4gIFRoZSB1cGRhdGVkIHNldCBvZiByZWNvcmRz CiAgIHJlcHJlc2VudHMgbm8gaW1wYWN0IG9uIElBTkEsIHNpbmNlIHRoZSB3b3JrIHRvIGNy ZWF0ZSBpdCB3aWxsIGJlCiAgIHBlcmZvcm1lZCBleHRlcm5hbGx5LgoKICAgRnV0dXJlIHdv cmsgb24gdGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSBTSEFMTCBiZSBsaW1pdGVkIHRv CiAgIGluc2VydGluZyBvciByZXBsYWNpbmcgd2hvbGUgcmVjb3JkcyBwcmVmb3JtYXR0ZWQg Zm9yIElBTkEgYnkgdGhlCiAgIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBhcyBkZXNjcmli ZWQgaW4gU2VjdGlvbiAzLjMgb2YgdGhpcyBkb2N1bWVudAogICBhbmQgYXJjaGl2aW5nIHRo ZSBmb3J3YXJkZWQgcmVnaXN0cmF0aW9uIGZvcm0uCgogICBFYWNoIHJlY29yZCBNVVNUIGJl IHNlbnQgdG8gaWFuYUBpYW5hLm9yZyB3aXRoIGEgc3ViamVjdCBsaW5lCiAgIGluZGljYXRp bmcgd2hldGhlciB0aGUgZW5jbG9zZWQgcmVjb3JkIGlzIGFuIGluc2VydGlvbiBvZiBhIG5l dwogICByZWNvcmQgKGluZGljYXRlZCBieSB0aGUgd29yZCAiSU5TRVJUIiBpbiB0aGUgc3Vi amVjdCBsaW5lKSBvciBhCiAgIHJlcGxhY2VtZW50IG9mIGFuIGV4aXN0aW5nIHJlY29yZCAo aW5kaWNhdGVkIGJ5IHRoZSB3b3JkICJNT0RJRlkiIGluCiAgIHRoZSBzdWJqZWN0IGxpbmUp LiAgUmVjb3JkcyBNVVNUIE5PVCBiZSBkZWxldGVkIGZyb20gdGhlIHJlZ2lzdHJ5LgogICBJ QU5BIE1VU1QgcGxhY2UgYW55IGluc2VydGVkIG9yIG1vZGlmaWVkIHJlY29yZHMgaW50byB0 aGUgYXBwcm9wcmlhdGUKICAgc2VjdGlvbiBvZiB0aGUgbGFuZ3VhZ2Ugc3VidGFnIHJlZ2lz dHJ5LCBncm91cGluZyB0aGUgcmVjb3JkcyBieQogICB0aGVpciAnVHlwZScgZmllbGQuICBJ bnNlcnRlZCByZWNvcmRzIE1BWSBiZSBwbGFjZWQgYW55d2hlcmUgaW4gdGhlCiAgIGFwcHJv cHJpYXRlIHNlY3Rpb247IHRoZXJlIGlzIG5vIGd1YXJhbnRlZSBvZiB0aGUgb3JkZXIgb2Yg dGhlCiAgIHJlY29yZHMgYmV5b25kIGdyb3VwaW5nIHRoZW0gdG9nZXRoZXIgYnkgJ1R5cGUn LiAgTW9kaWZpZWQgcmVjb3JkcwogICBNVVNUIG92ZXJ3cml0ZSB0aGUgcmVjb3JkIHRoZXkg cmVwbGFjZS4KCiAgIEluY2x1ZGVkIGluIGFueSByZXF1ZXN0IHRvIGluc2VydCBvciBtb2Rp ZnkgcmVjb3JkcyBNVVNUIGJlIGEgbmV3CiAgIEZpbGUtRGF0ZSByZWNvcmQuICBUaGlzIHJl Y29yZCBNVVNUIGJlIHBsYWNlZCBmaXJzdCBpbiB0aGUgcmVnaXN0cnkuCiAgIEluIHRoZSBl dmVudCB0aGF0IHRoZSBGaWxlLURhdGUgcmVjb3JkIHByZXNlbnQgaW4gdGhlIHJlZ2lzdHJ5 IGhhcyBhCiAgIGxhdGVyIGRhdGUgdGhhbiB0aGUgcmVjb3JkIGJlaW5nIGluc2VydGVkIG9y IG1vZGlmaWVkLCB0aGUgZXhpc3RpbmcKICAgcmVjb3JkIE1VU1QgYmUgcHJlc2VydmVkLgoK NS4yLiAgRXh0ZW5zaW9ucyBSZWdpc3RyeQoKICAgVGhlIExhbmd1YWdlIFRhZyBFeHRlbnNp b25zIFJlZ2lzdHJ5IGNhbiBjb250YWluIGF0IG1vc3QgMzUgcmVjb3JkcwogICBhbmQgdGh1 cyBjaGFuZ2VzIHRvIHRoaXMgcmVnaXN0cnkgYXJlIGV4cGVjdGVkIHRvIGJlIHZlcnkgaW5m cmVxdWVudC4KCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDE1 LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDQ3XQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNgoK CiAgIEZ1dHVyZSB3b3JrIGJ5IElBTkEgb24gdGhlIExhbmd1YWdlIFRhZyBFeHRlbnNpb25z IFJlZ2lzdHJ5IGlzCiAgIGxpbWl0ZWQgdG8gdHdvIGNhc2VzLiAgRmlyc3QsIHRoZSBJRVNH IE1BWSByZXF1ZXN0IHRoYXQgbmV3IHJlY29yZHMKICAgYmUgaW5zZXJ0ZWQgaW50byB0aGlz IHJlZ2lzdHJ5IGZyb20gdGltZSB0byB0aW1lLiAgVGhlc2UgcmVxdWVzdHMKICAgTVVTVCBp bmNsdWRlIHRoZSByZWNvcmQgdG8gaW5zZXJ0IGluIHRoZSBleGFjdCBmb3JtYXQgZGVzY3Jp YmVkIGluCiAgIFNlY3Rpb24gMy43LiAgSW4gYWRkaXRpb24sIHRoZXJlIE1BWSBiZSBvY2Nh c2lvbmFsIHJlcXVlc3RzIGZyb20gdGhlCiAgIG1haW50YWluaW5nIGF1dGhvcml0eSBmb3Ig YSBzcGVjaWZpYyBleHRlbnNpb24gdG8gdXBkYXRlIHRoZSBjb250YWN0CiAgIGluZm9ybWF0 aW9uIG9yIFVSTHMgaW4gdGhlIHJlY29yZC4gIFRoZXNlIHJlcXVlc3RzIE1VU1QgaW5jbHVk ZSB0aGUKICAgY29tcGxldGUsIHVwZGF0ZWQgcmVjb3JkLiAgSUFOQSBpcyBub3QgcmVzcG9u c2libGUgZm9yIHZhbGlkYXRpbmcgdGhlCiAgIGluZm9ybWF0aW9uIHByb3ZpZGVkLCBvbmx5 IHRoYXQgaXQgaXMgcHJvcGVybHkgZm9ybWF0dGVkLiAgSXQgc2hvdWxkCiAgIHJlYXNvbmFi bHkgYmUgc2VlbiB0byBjb21lIGZyb20gdGhlIG1haW50YWluaW5nIGF1dGhvcml0eSBuYW1l ZCBpbgogICB0aGUgcmVjb3JkIHByZXNlbnQgaW4gdGhlIHJlZ2lzdHJ5LgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAg IEV4cGlyZXMgTWFyY2ggMTUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgNDhdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAg IFNlcHRlbWJlciAyMDA2CgoKNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBMYW5n dWFnZSB0YWdzIHVzZWQgaW4gY29udGVudCBuZWdvdGlhdGlvbiwgbGlrZSBhbnkgb3RoZXIg aW5mb3JtYXRpb24KICAgZXhjaGFuZ2VkIG9uIHRoZSBJbnRlcm5ldCwgbWlnaHQgYmUgYSBz b3VyY2Ugb2YgY29uY2VybiBiZWNhdXNlIHRoZXkKICAgbWlnaHQgYmUgdXNlZCB0byBpbmZl ciB0aGUgbmF0aW9uYWxpdHkgb2YgdGhlIHNlbmRlciwgYW5kIHRodXMKICAgaWRlbnRpZnkg cG90ZW50aWFsIHRhcmdldHMgZm9yIHN1cnZlaWxsYW5jZS4KCiAgIFRoaXMgaXMgYSBzcGVj aWFsIGNhc2Ugb2YgdGhlIGdlbmVyYWwgcHJvYmxlbSB0aGF0IGFueXRoaW5nIHNlbnQgaXMK ICAgdmlzaWJsZSB0byB0aGUgcmVjZWl2aW5nIHBhcnR5IGFuZCBwb3NzaWJseSB0byB0aGly ZCBwYXJ0aWVzIGFzIHdlbGwuCiAgIEl0IGlzIHVzZWZ1bCB0byBiZSBhd2FyZSB0aGF0IHN1 Y2ggY29uY2VybnMgY2FuIGV4aXN0IGluIHNvbWUgY2FzZXMuCgogICBUaGUgZXZhbHVhdGlv biBvZiB0aGUgZXhhY3QgbWFnbml0dWRlIG9mIHRoZSB0aHJlYXQsIGFuZCBhbnkgcG9zc2li bGUKICAgY291bnRlcm1lYXN1cmVzLCBpcyBsZWZ0IHRvIGVhY2ggYXBwbGljYXRpb24gcHJv dG9jb2wgKHNlZSBCQ1AgNzIKICAgW1JGQzM1NTJdIGZvciBiZXN0IGN1cnJlbnQgcHJhY3Rp Y2UgZ3VpZGFuY2Ugb24gc2VjdXJpdHkgdGhyZWF0cyBhbmQKICAgZGVmZW5zZXMpLgoKICAg VGhlIGxhbmd1YWdlIHRhZyBhc3NvY2lhdGVkIHdpdGggYSBwYXJ0aWN1bGFyIGluZm9ybWF0 aW9uIGl0ZW0gaXMgb2YKICAgbm8gY29uc2VxdWVuY2Ugd2hhdHNvZXZlciBpbiBkZXRlcm1p bmluZyB3aGV0aGVyIHRoYXQgY29udGVudCBtaWdodAogICBjb250YWluIHBvc3NpYmxlIGhv bW9ncmFwaHMuICBUaGUgZmFjdCB0aGF0IGEgdGV4dCBpcyB0YWdnZWQgYXMgYmVpbmcKICAg aW4gb25lIGxhbmd1YWdlIG9yIHVzaW5nIGEgcGFydGljdWxhciBzY3JpcHQgc3VidGFnIHBy b3ZpZGVzIG5vCiAgIGFzc3VyYW5jZSB3aGF0c29ldmVyIHRoYXQgaXQgZG9lcyBub3QgY29u dGFpbiBjaGFyYWN0ZXJzIGZyb20gc2NyaXB0cwogICBvdGhlciB0aGFuIHRoZSBvbmUocykg YXNzb2NpYXRlZCB3aXRoIG9yIHNwZWNpZmllZCBieSB0aGF0IGxhbmd1YWdlCiAgIHRhZy4K CiAgIFNpbmNlIHRoZXJlIGlzIG5vIGxpbWl0IHRvIHRoZSBudW1iZXIgb2YgdmFyaWFudCwg cHJpdmF0ZSB1c2UsIGFuZAogICBleHRlbnNpb24gc3VidGFncywgYW5kIGNvbnNlcXVlbnRs eSBubyBsaW1pdCBvbiB0aGUgcG9zc2libGUgbGVuZ3RoCiAgIG9mIGEgdGFnLCBpbXBsZW1l bnRhdGlvbnMgbmVlZCB0byBndWFyZCBhZ2FpbnN0IGJ1ZmZlciBvdmVyZmxvdwogICBhdHRh Y2tzLiAgU2VlIFNlY3Rpb24gNC4zIGZvciBkZXRhaWxzIG9uIGxhbmd1YWdlIHRhZyB0cnVu Y2F0aW9uLAogICB3aGljaCBjYW4gb2NjdXIgYXMgYSBjb25zZXF1ZW5jZSBvZiBkZWZlbnNl cyBhZ2FpbnN0IGJ1ZmZlciBvdmVyZmxvdy4KCiAgIEFsdGhvdWdoIHRoZSBzcGVjaWZpY2F0 aW9uIG9mIHZhbGlkIHN1YnRhZ3MgZm9yIGFuIGV4dGVuc2lvbiAoc2VlCiAgIFNlY3Rpb24g My43KSBNVVNUIGJlIGF2YWlsYWJsZSBvdmVyIHRoZSBJbnRlcm5ldCwgaW1wbGVtZW50YXRp b25zCiAgIFNIT1VMRCBOT1QgbWVjaGFuaWNhbGx5IGRlcGVuZCBvbiBpdCBiZWluZyBhbHdh eXMgYWNjZXNzaWJsZSwgdG8KICAgcHJldmVudCBkZW5pYWwtb2Ytc2VydmljZSBhdHRhY2tz LgoKCgoKCgoKCgoKCgoKCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1h cmNoIDE1LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDQ5XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIg MjAwNgoKCjcuICBDaGFyYWN0ZXIgU2V0IENvbnNpZGVyYXRpb25zCgogICBUaGUgc3ludGF4 IGluIHRoaXMgZG9jdW1lbnQgcmVxdWlyZXMgdGhhdCBsYW5ndWFnZSB0YWdzIHVzZSBvbmx5 IHRoZQogICBjaGFyYWN0ZXJzIEEtWiwgYS16LCAwLTksIGFuZCBIWVBIRU4tTUlOVVMsIHdo aWNoIGFyZSBwcmVzZW50IGluIG1vc3QKICAgY2hhcmFjdGVyIHNldHMsIHNvIHRoZSBjb21w b3NpdGlvbiBvZiBsYW5ndWFnZSB0YWdzIHNob3VsZCBub3QgaGF2ZQogICBhbnkgY2hhcmFj dGVyIHNldCBpc3N1ZXMuCgogICBSZW5kZXJpbmcgb2YgY2hhcmFjdGVycyBiYXNlZCBvbiB0 aGUgY29udGVudCBvZiBhIGxhbmd1YWdlIHRhZyBpcyBub3QKICAgYWRkcmVzc2VkIGluIHRo aXMgbWVtby4gIEhpc3RvcmljYWxseSwgc29tZSBsYW5ndWFnZXMgaGF2ZSByZWxpZWQgb24K ICAgdGhlIHVzZSBvZiBzcGVjaWZpYyBjaGFyYWN0ZXIgc2V0cyBvciBvdGhlciBpbmZvcm1h dGlvbiBpbiBvcmRlciB0bwogICBpbmZlciBob3cgYSBzcGVjaWZpYyBjaGFyYWN0ZXIgc2hv dWxkIGJlIHJlbmRlcmVkIChub3RhYmx5IHRoaXMKICAgYXBwbGllcyB0byBsYW5ndWFnZS0g YW5kIGN1bHR1cmUtc3BlY2lmaWMgdmFyaWF0aW9ucyBvZiBIYW4KICAgaWRlb2dyYXBocyBh cyB1c2VkIGluIEphcGFuZXNlLCBDaGluZXNlLCBhbmQgS29yZWFuKS4gIFdoZW4gbGFuZ3Vh Z2UKICAgdGFncyBhcmUgYXBwbGllZCB0byBzcGFucyBvZiB0ZXh0LCByZW5kZXJpbmcgZW5n aW5lcyBzb21ldGltZXMgdXNlCiAgIHRoYXQgaW5mb3JtYXRpb24gaW4gZGVjaWRpbmcgd2hp Y2ggZm9udCB0byB1c2UgaW4gdGhlIGFic2VuY2Ugb2YKICAgb3RoZXIgaW5mb3JtYXRpb24s IHBhcnRpY3VsYXJseSB3aGVyZSBsYW5ndWFnZXMgd2l0aCBkaXN0aW5jdCB3cml0aW5nCiAg IHRyYWRpdGlvbnMgdXNlIHRoZSBzYW1lIGNoYXJhY3RlcnMuCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJj aCAxNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSA1MF0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIw MDYKCgo4LiAgQ2hhbmdlcyBmcm9tIFJGQyA0NjQ2CgogICBUaGUgbWFpbiBnb2FsIGZvciB0 aGlzIHJldmlzaW9uIG9mIHRoaXMgZG9jdW1lbnQgd2FzIHRvIGluY29ycG9yYXRlCiAgIElT TyA2MzktMyBhbmQgaXRzIGF0dGVuZGVudCBzZXQgb2YgbGFuZ3VhZ2UgY29kZXMgaW50byB0 aGUgSUFOQQogICBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnksIHBlcm1pdHRpbmcgdGhlIGlk ZW50aWZpY2F0aW9uIG9mIG1hbnkgbW9yZQogICBsYW5ndWFnZXMgYW5kIGRpYWxlY3RzIHRo YW4gcHJldmlvdXNseSBzdXBwb3J0ZWQuCgogICBUaGUgc3BlY2lmaWMgY2hhbmdlcyBpbiB0 aGlzIGRvY3VtZW50IHRvIG1lZXQgdGhlc2UgZ29hbHMgYXJlOgoKICAgbyAgRGVmaW5lcyB0 aGUgaW5jb3Jwb3JhdGlvbiBvZiBJU08gNjM5LTMuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFy Y2ggMTUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgNTFdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAy MDA2CgoKOS4gIFJlZmVyZW5jZXMKCjkuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBb SVNPMTA2NDZdCiAgICAgICAgICAgICAgSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9y IFN0YW5kYXJkaXphdGlvbiwgIklTTy9JRUMKICAgICAgICAgICAgICAxMDY0NjoyMDAzLiBJ bmZvcm1hdGlvbiB0ZWNobm9sb2d5IC0tIFVuaXZlcnNhbCBNdWx0aXBsZS0KICAgICAgICAg ICAgICBPY3RldCBDb2RlZCBDaGFyYWN0ZXIgU2V0IChVQ1MpIiwgMjAwMy4KCiAgIFtJU08x NTkyNF0KICAgICAgICAgICAgICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3Rh bmRhcmRpemF0aW9uLCAiSVNPCiAgICAgICAgICAgICAgMTU5MjQ6MjAwNC4gSW5mb3JtYXRp b24gYW5kIGRvY3VtZW50YXRpb24gLS0gQ29kZXMgZm9yIHRoZQogICAgICAgICAgICAgIHJl cHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIHNjcmlwdHMiLCBKYW51YXJ5IDIwMDQuCgogICBb SVNPMzE2Ni0xXQogICAgICAgICAgICAgIEludGVybmF0aW9uYWwgT3JnYW5pemF0aW9uIGZv ciBTdGFuZGFyZGl6YXRpb24sICJJU08gMzE2Ni0KICAgICAgICAgICAgICAxOjE5OTcuIENv ZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2YgY291bnRyaWVzCiAgICAg ICAgICAgICAgYW5kIHRoZWlyIHN1YmRpdmlzaW9ucyAtLSBQYXJ0IDE6IENvdW50cnkgY29k ZXMiLCAxOTk3LgoKICAgW0lTTzYzOS0xXQogICAgICAgICAgICAgIEludGVybmF0aW9uYWwg T3JnYW5pemF0aW9uIGZvciBTdGFuZGFyZGl6YXRpb24sICJJU08gNjM5LQogICAgICAgICAg ICAgIDE6MjAwMi4gQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBuYW1lcyBvZiBs YW5ndWFnZXMKICAgICAgICAgICAgICAtLSBQYXJ0IDE6IEFscGhhLTIgY29kZSIsIDIwMDIu CgogICBbSVNPNjM5LTJdCiAgICAgICAgICAgICAgSW50ZXJuYXRpb25hbCBPcmdhbml6YXRp b24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIklTTyA2MzktCiAgICAgICAgICAgICAgMjoxOTk4 LiBDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIGxhbmd1YWdlcwog ICAgICAgICAgICAgIC0tIFBhcnQgMjogQWxwaGEtMyBjb2RlLCBmaXJzdCBlZGl0aW9uIiwg MTk5OC4KCiAgIFtJU082NDZdICAgSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0 YW5kYXJkaXphdGlvbiwgIklTTy9JRUMKICAgICAgICAgICAgICA2NDY6MTk5MSwgSW5mb3Jt YXRpb24gdGVjaG5vbG9neSAtLSBJU08gNy1iaXQgY29kZWQKICAgICAgICAgICAgICBjaGFy YWN0ZXIgc2V0IGZvciBpbmZvcm1hdGlvbiBpbnRlcmNoYW5nZS4iLCAxOTkxLgoKICAgW1JG QzIwMjZdICBCcmFkbmVyLCBTLiwgIlRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgUHJvY2VzcyAt LSBSZXZpc2lvbgogICAgICAgICAgICAgIDMiLCBCQ1AgOSwgUkZDIDIwMjYsIE9jdG9iZXIg MTk5Ni4KCiAgIFtSRkMyMDI4XSAgSG92ZXksIFIuIGFuZCBTLiBCcmFkbmVyLCAiVGhlIE9y Z2FuaXphdGlvbnMgSW52b2x2ZWQgaW4KICAgICAgICAgICAgICB0aGUgSUVURiBTdGFuZGFy ZHMgUHJvY2VzcyIsIEJDUCAxMSwgUkZDIDIwMjgsCiAgICAgICAgICAgICAgT2N0b2JlciAx OTk2LgoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGlu IFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBC Q1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LgoKICAgW1JGQzI0MzRdICBOYXJ0ZW4sIFQu IGFuZCBILiBBbHZlc3RyYW5kLCAiR3VpZGVsaW5lcyBmb3IgV3JpdGluZyBhbgogICAgICAg ICAgICAgIElBTkEgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzIiwgQkNQIDI2LCBS RkMgMjQzNCwKICAgICAgICAgICAgICBPY3RvYmVyIDE5OTguCgogICBbUkZDMjg2MF0gIENh cnBlbnRlciwgQi4sIEJha2VyLCBGLiwgYW5kIE0uIFJvYmVydHMsICJNZW1vcmFuZHVtIG9m CgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDE1LCAyMDA3ICAg ICAgICAgICAgICAgIFtQYWdlIDUyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBs YW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNgoKCiAgICAgICAg ICAgICAgVW5kZXJzdGFuZGluZyBDb25jZXJuaW5nIHRoZSBUZWNobmljYWwgV29yayBvZiB0 aGUKICAgICAgICAgICAgICBJbnRlcm5ldCBBc3NpZ25lZCBOdW1iZXJzIEF1dGhvcml0eSIs IFJGQyAyODYwLCBKdW5lIDIwMDAuCgogICBbUkZDMzMzOV0gIEtseW5lLCBHLiBhbmQgQy4g TmV3bWFuLCAiRGF0ZSBhbmQgVGltZSBvbiB0aGUgSW50ZXJuZXQ6CiAgICAgICAgICAgICAg VGltZXN0YW1wcyIsIFJGQyAzMzM5LCBKdWx5IDIwMDIuCgogICBbUkZDNDIzNF0gIENyb2Nr ZXIsIEQuIGFuZCBQLiBPdmVyZWxsLCAiQXVnbWVudGVkIEJORiBmb3IgU3ludGF4CiAgICAg ICAgICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBSRkMgNDIzNCwgT2N0b2JlciAyMDA1 LgoKICAgW1JGQzQ2NDddICBQaGlsbGlwcywgQS4sIEVkLiBhbmQgTS4gRGF2aXMsIEVkLiwg Ik1hdGNoaW5nIG9mIExhbmd1YWdlCiAgICAgICAgICAgICAgVGFncyIsIFNlcHRlbWJlciAy MDA2LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LmlldGYub3JnL3JmYy9yZmM0NjQ3LnR4 dD4uCgogICBbVU5fTS40OV0gIFN0YXRpc3RpY3MgRGl2aXNpb24sIFVuaXRlZCBOYXRpb25z LCAiU3RhbmRhcmQgQ291bnRyeSBvcgogICAgICAgICAgICAgIEFyZWEgQ29kZXMgZm9yIFN0 YXRpc3RpY2FsIFVzZSIsIFVOIFN0YW5kYXJkIENvdW50cnkgb3IKICAgICAgICAgICAgICBB cmVhIENvZGVzIGZvciBTdGF0aXN0aWNhbCBVc2UsIFJldmlzaW9uIDQgKFVuaXRlZCBOYXRp b25zCiAgICAgICAgICAgICAgcHVibGljYXRpb24sIFNhbGVzIE5vLiA5OC5YVklJLjksIEp1 bmUgMTk5OS4KCjkuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMxNzY2XSAg QWx2ZXN0cmFuZCwgSC4sICJUYWdzIGZvciB0aGUgSWRlbnRpZmljYXRpb24gb2YKICAgICAg ICAgICAgICBMYW5ndWFnZXMiLCBSRkMgMTc2NiwgTWFyY2ggMTk5NS4KCiAgIFtSRkMyMDQ3 XSAgTW9vcmUsIEsuLCAiTUlNRSAoTXVsdGlwdXJwb3NlIEludGVybmV0IE1haWwgRXh0ZW5z aW9ucykKICAgICAgICAgICAgICBQYXJ0IFRocmVlOiBNZXNzYWdlIEhlYWRlciBFeHRlbnNp b25zIGZvciBOb24tQVNDSUkgVGV4dCIsCiAgICAgICAgICAgICAgUkZDIDIwNDcsIE5vdmVt YmVyIDE5OTYuCgogICBbUkZDMjIzMV0gIEZyZWVkLCBOLiBhbmQgSy4gTW9vcmUsICJNSU1F IFBhcmFtZXRlciBWYWx1ZSBhbmQgRW5jb2RlZAogICAgICAgICAgICAgIFdvcmQgRXh0ZW5z aW9uczogQ2hhcmFjdGVyIFNldHMsIExhbmd1YWdlcywgYW5kCiAgICAgICAgICAgICAgQ29u dGludWF0aW9ucyIsIFJGQyAyMjMxLCBOb3ZlbWJlciAxOTk3LgoKICAgW1JGQzI3ODFdICBI b2ZmbWFuLCBQLiBhbmQgRi4gWWVyZ2VhdSwgIlVURi0xNiwgYW4gZW5jb2Rpbmcgb2YgSVNP CiAgICAgICAgICAgICAgMTA2NDYiLCBSRkMgMjc4MSwgRmVicnVhcnkgMjAwMC4KCiAgIFtS RkMzMDY2XSAgQWx2ZXN0cmFuZCwgSC4sICJUYWdzIGZvciB0aGUgSWRlbnRpZmljYXRpb24g b2YKICAgICAgICAgICAgICBMYW5ndWFnZXMiLCBCQ1AgNDcsIFJGQyAzMDY2LCBKYW51YXJ5 IDIwMDEuCgogICBbUkZDMzU1Ml0gIFJlc2NvcmxhLCBFLiBhbmQgQi4gS29ydmVyLCAiR3Vp ZGVsaW5lcyBmb3IgV3JpdGluZyBSRkMKICAgICAgICAgICAgICBUZXh0IG9uIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zIiwgQkNQIDcyLCBSRkMgMzU1MiwKICAgICAgICAgICAgICBKdWx5 IDIwMDMuCgogICBbUkZDNDY0Nl0gIFBoaWxsaXBzLCBBLiwgRWQuIGFuZCBNLiBEYXZpcywg RWQuLCAiVGFncyBmb3IgdGhlCiAgICAgICAgICAgICAgSWRlbnRpZmljYXRpb24gb2YgTGFu Z3VhZ2VzIiwgU2VwdGVtYmVyIDIwMDYsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cuaWV0 Zi5vcmcvcmZjL3JmYzQ2NDYudHh0Pi4KCiAgIFtVbmljb2RlXSAgVW5pY29kZSBDb25zb3J0 aXVtLCAiVGhlIFVuaWNvZGUgQ29uc29ydGl1bS4gVGhlIFVuaWNvZGUKICAgICAgICAgICAg ICBTdGFuZGFyZCwgVmVyc2lvbiA1LjAsIChCb3N0b24sIE1BLCBBZGRpc29uLVdlc2xleSwg MjAwMy4KICAgICAgICAgICAgICBJU0JOIDAtMzIxLTQ5MDgxLTApIiwgSmFudWFyeSAyMDA3 LgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAxNSwgMjAwNyAg ICAgICAgICAgICAgICBbUGFnZSA1M10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg bGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDYKCgogICBbWE1M MTBdICAgIEJyYXkgKGV0IGFsKSwgVC4sICJFeHRlbnNpYmxlIE1hcmt1cCBMYW5ndWFnZSAo WE1MKSAxLjAiLAogICAgICAgICAgICAgIDAyIDIwMDQuCgogICBbWE1MU2NoZW1hXQogICAg ICAgICAgICAgIEJpcm9uLCBQLiwgRWQuIGFuZCBBLiBNYWxob3RyYSwgRWQuLCAiWE1MIFNj aGVtYSBQYXJ0IDI6CiAgICAgICAgICAgICAgRGF0YXR5cGVzIFNlY29uZCBFZGl0aW9uIiwg MTAgMjAwNCwgPAogICAgICAgICAgICAgIGh0dHA6Ly93d3cudzMub3JnL1RSL3htbHNjaGVt YS0yLz4uCgogICBbaW5pdGlhbC1yZWdpc3RyeV0KICAgICAgICAgICAgICBFd2VsbCwgRC4s IEVkLiwgIkluaXRpYWwgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IiwKICAgICAgICAgICAg ICBKdW5lIDIwMDUsIDxodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8KICAg ICAgICAgICAgICBkcmFmdC1pZXRmLWx0cnUtaW5pdGlhbC1yZWdpc3RyeS0wMC50eHQ+LgoK ICAgW2lzbzYzOS5wcmluXQogICAgICAgICAgICAgIElTTyA2MzkgSm9pbnQgQWR2aXNvcnkg Q29tbWl0dGVlLCAiSVNPIDYzOSBKb2ludCBBZHZpc29yeQogICAgICAgICAgICAgIENvbW1p dHRlZTogIFdvcmtpbmcgcHJpbmNpcGxlcyBmb3IgSVNPIDYzOSBtYWludGVuYW5jZSIsCiAg ICAgICAgICAgICAgTWFyY2ggMjAwMCwKICAgICAgICAgICAgICA8aHR0cDovL3d3dy5sb2Mu Z292L3N0YW5kYXJkcy9pc282MzktMi8KICAgICAgICAgICAgICBpc282MzlqYWNfbjNyLmh0 bWw+LgoKICAgW3JlY29yZC1qYXJdCiAgICAgICAgICAgICAgUmF5bW9uZCwgRS4sICJUaGUg QXJ0IG9mIFVuaXggUHJvZ3JhbW1pbmciLCAyMDAzLAogICAgICAgICAgICAgIDx1cm46aXNi bjowLTEzLTE0MjkwMS05Pi4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClBoaWxsaXBz ICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDE1LCAyMDA3ICAgICAgICAgICAgICAg IFtQYWdlIDU0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdp c3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNgoKCkFwcGVuZGl4IEEuICBBY2tub3ds ZWRnZW1lbnRzCgogICBBbnkgbGlzdCBvZiBjb250cmlidXRvcnMgaXMgYm91bmQgdG8gYmUg aW5jb21wbGV0ZTsgcGxlYXNlIHJlZ2FyZCB0aGUKICAgZm9sbG93aW5nIGFzIG9ubHkgYSBz ZWxlY3Rpb24gZnJvbSB0aGUgZ3JvdXAgb2YgcGVvcGxlIHdobyBoYXZlCiAgIGNvbnRyaWJ1 dGVkIHRvIG1ha2UgdGhpcyBkb2N1bWVudCB3aGF0IGl0IGlzIHRvZGF5LgoKICAgVGhlIGNv bnRyaWJ1dG9ycyB0byBSRkMgNDY0NiwgUkZDIDQ2NDcsIFJGQyAzMDY2LCBhbmQgUkZDIDE3 NjYsIHRoZQogICBwcmVjdXJzb3JzIG9mIHRoaXMgZG9jdW1lbnQsIG1hZGUgZW5vcm1vdXMg Y29udHJpYnV0aW9ucyBkaXJlY3RseSBvcgogICBpbmRpcmVjdGx5IHRvIHRoaXMgZG9jdW1l bnQgYW5kIGFyZSBnZW5lcmFsbHkgcmVzcG9uc2libGUgZm9yIHRoZQogICBzdWNjZXNzIG9m IGxhbmd1YWdlIHRhZ3MuCgogICBUaGUgZm9sbG93aW5nIHBlb3BsZSBjb250cmlidXRlZCB0 byB0aGlzIGRvY3VtZW50OgoKICAgU3RlcGhhbmUgQm9ydHptZXllciwgUGV0ZXIgQ29uc3Rh YmxlLCBKb2huIENvd2FuLCBGcmFuayBFbGxlcm1hbiwKICAgUmFuZHkgUHJlc3VobiwgYW5k IG1hbnksIG1hbnkgb3RoZXJzLgoKICAgVmVyeSBzcGVjaWFsIHRoYW5rcyBtdXN0IGdvIHRv IEhhcmFsZCBUdmVpdCBBbHZlc3RyYW5kLCB3aG8KICAgb3JpZ2luYXRlZCBSRkNzIDE3NjYg YW5kIDMwNjYsIGFuZCB3aXRob3V0IHdob20gdGhpcyBkb2N1bWVudCB3b3VsZAogICBub3Qg aGF2ZSBiZWVuIHBvc3NpYmxlLiAgU3BlY2lhbCB0aGFua3MgbXVzdCBnbyB0byBNaWNoYWVs IEV2ZXJzb24sCiAgIHdobyBoYXMgc2VydmVkIGFzIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdl ciBmb3IgYWxtb3N0IHRoZSBjb21wbGV0ZQogICBwZXJpb2Qgc2luY2UgdGhlIHB1YmxpY2F0 aW9uIG9mIFJGQyAxNzY2LiAgU3BlY2lhbCB0aGFua3MgdG8gRG91ZwogICBFd2VsbCwgZm9y IGhpcyBwcm9kdWN0aW9uIG9mIHRoZSBmaXJzdCBjb21wbGV0ZSBzdWJ0YWcgcmVnaXN0cnks IGFuZAogICBoaXMgd29yayBpbiBwcm9kdWNpbmcgYSB0ZXN0IHBhcnNlciBmb3IgdmVyaWZ5 aW5nIGxhbmd1YWdlIHRhZ3MuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpQaGlsbGlw cyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAxNSwgMjAwNyAgICAgICAgICAgICAg ICBbUGFnZSA1NV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDYKCgpBcHBlbmRpeCBCLiAgRXhhbXBs ZXMgb2YgTGFuZ3VhZ2UgVGFncyAoSW5mb3JtYXRpdmUpCgogICBTaW1wbGUgbGFuZ3VhZ2Ug c3VidGFnOgoKICAgICAgZGUgKEdlcm1hbikKCiAgICAgIGZyIChGcmVuY2gpCgogICAgICBq YSAoSmFwYW5lc2UpCgogICAgICBpLWVub2NoaWFuIChleGFtcGxlIG9mIGEgZ3JhbmRmYXRo ZXJlZCB0YWcpCgogICBMYW5ndWFnZSBzdWJ0YWcgcGx1cyBTY3JpcHQgc3VidGFnOgoKICAg ICAgemgtSGFudCAoQ2hpbmVzZSB3cml0dGVuIHVzaW5nIHRoZSBUcmFkaXRpb25hbCBDaGlu ZXNlIHNjcmlwdCkKCiAgICAgIHpoLUhhbnMgKENoaW5lc2Ugd3JpdHRlbiB1c2luZyB0aGUg U2ltcGxpZmllZCBDaGluZXNlIHNjcmlwdCkKCiAgICAgIHNyLUN5cmwgKFNlcmJpYW4gd3Jp dHRlbiB1c2luZyB0aGUgQ3lyaWxsaWMgc2NyaXB0KQoKICAgICAgc3ItTGF0biAoU2VyYmlh biB3cml0dGVuIHVzaW5nIHRoZSBMYXRpbiBzY3JpcHQpCgogICBMYW5ndWFnZS1TY3JpcHQt UmVnaW9uOgoKICAgICAgemgtSGFucy1DTiAoQ2hpbmVzZSB3cml0dGVuIHVzaW5nIHRoZSBT aW1wbGlmaWVkIHNjcmlwdCBhcyB1c2VkIGluCiAgICAgIG1haW5sYW5kIENoaW5hKQoKICAg ICAgc3ItTGF0bi1DUyAoU2VyYmlhbiB3cml0dGVuIHVzaW5nIHRoZSBMYXRpbiBzY3JpcHQg YXMgdXNlZCBpbgogICAgICBTZXJiaWEgYW5kIE1vbnRlbmVncm8pCgogICBMYW5ndWFnZS1W YXJpYW50OgoKICAgICAgc2wtcm96YWogKFJlc2lhbiBkaWFsZWN0IG9mIFNsb3ZlbmlhbgoK ICAgICAgc2wtbmVkaXMgKE5hZGl6YSBkaWFsZWN0IG9mIFNsb3ZlbmlhbikKCiAgIExhbmd1 YWdlLVJlZ2lvbi1WYXJpYW50OgoKICAgICAgZGUtQ0gtMTkwMSAoR2VybWFuIGFzIHVzZWQg aW4gU3dpdHplcmxhbmQgdXNpbmcgdGhlIDE5MDEgdmFyaWFudAogICAgICBbb3J0aG9ncmFw aHldKQoKICAgICAgc2wtSVQtbmVkaXMgKFNsb3ZlbmlhbiBhcyB1c2VkIGluIEl0YWx5LCBO YWRpemEgZGlhbGVjdCkKCiAgIExhbmd1YWdlLVNjcmlwdC1SZWdpb24tVmFyaWFudDoKCgoK CgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDE1LCAyMDA3ICAg ICAgICAgICAgICAgIFtQYWdlIDU2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBs YW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNgoKCiAgICAgIHNs LUxhdG4tSVQtbmVkaXMgKE5hZGl6YSBkaWFsZWN0IG9mIFNsb3ZlbmlhbiB3cml0dGVuIHVz aW5nIHRoZQogICAgICBMYXRpbiBzY3JpcHQgYXMgdXNlZCBpbiBJdGFseS4gIE5vdGUgdGhh dCB0aGlzIHRhZyBpcyBOT1QKICAgICAgUkVDT01NRU5ERUQgYmVjYXVzZSBzdWJ0YWcgJ3Ns JyBoYXMgYSBTdXBwcmVzcy1TY3JpcHQgdmFsdWUgb2YKICAgICAgJ0xhdG4nKQoKICAgTGFu Z3VhZ2UtUmVnaW9uOgoKICAgICAgZGUtREUgKEdlcm1hbiBmb3IgR2VybWFueSkKCiAgICAg IGVuLVVTIChFbmdsaXNoIGFzIHVzZWQgaW4gdGhlIFVuaXRlZCBTdGF0ZXMpCgogICAgICBl cy00MTkgKFNwYW5pc2ggYXBwcm9wcmlhdGUgZm9yIHRoZSBMYXRpbiBBbWVyaWNhIGFuZCBD YXJpYmJlYW4KICAgICAgcmVnaW9uIHVzaW5nIHRoZSBVTiByZWdpb24gY29kZSkKCiAgIFBy aXZhdGUgdXNlIHN1YnRhZ3M6CgogICAgICBkZS1DSC14LXBob25lYmsKCiAgICAgIGF6LUFy YWIteC1BWkUtZGVyYmVuZAoKICAgRXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyAoZXhhbXBs ZXMgT05MWTogZXh0ZW5kZWQgbGFuZ3VhZ2VzIE1VU1QgYmUKICAgZGVmaW5lZCBieSByZXZp c2lvbiBvciB1cGRhdGUgdG8gdGhpcyBkb2N1bWVudCk6CgogICAgICB6aC1taW4KCiAgICAg IHpoLW1pbi1uYW4tSGFudC1DTgoKICAgUHJpdmF0ZSB1c2UgcmVnaXN0cnkgdmFsdWVzOgoK ICAgICAgeC13aGF0ZXZlciAocHJpdmF0ZSB1c2UgdXNpbmcgdGhlIHNpbmdsZXRvbiAneCcp CgogICAgICBxYWEtUWFhYS1RTS14LXNvdXRoZXJuIChhbGwgcHJpdmF0ZSB0YWdzKQoKICAg ICAgZGUtUWFhYSAoR2VybWFuLCB3aXRoIGEgcHJpdmF0ZSBzY3JpcHQpCgogICAgICBzci1M YXRuLVFNIChTZXJiaWFuLCBMYXRpbi1zY3JpcHQsIHByaXZhdGUgcmVnaW9uKQoKICAgICAg c3ItUWFhYS1DUyAoU2VyYmlhbiwgcHJpdmF0ZSBzY3JpcHQsIGZvciBTZXJiaWEgYW5kIE1v bnRlbmVncm8pCgogICBUYWdzIHRoYXQgdXNlIGV4dGVuc2lvbnMgKGV4YW1wbGVzIE9OTFk6 IGV4dGVuc2lvbnMgTVVTVCBiZSBkZWZpbmVkCiAgIGJ5IHJldmlzaW9uIG9yIHVwZGF0ZSB0 byB0aGlzIGRvY3VtZW50IG9yIGJ5IFJGQyk6CgogICAgICBlbi1VUy11LWlzbGFtQ2FsCgog ICAgICB6aC1DTi1hLW15RXh0LXgtcHJpdmF0ZQoKCgoKCgpQaGlsbGlwcyAmIERhdmlzICAg ICAgICAgRXhwaXJlcyBNYXJjaCAxNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSA1N10K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgU2VwdGVtYmVyIDIwMDYKCgogICAgICBlbi1hLW15RXh0LWItYW5vdGhlcgoKICAg U29tZSBJbnZhbGlkIFRhZ3M6CgogICAgICBkZS00MTktREUgKHR3byByZWdpb24gdGFncykK CiAgICAgIGEtREUgKHVzZSBvZiBhIHNpbmdsZS1jaGFyYWN0ZXIgc3VidGFnIGluIHByaW1h cnkgcG9zaXRpb247IG5vdGUKICAgICAgdGhhdCB0aGVyZSBhcmUgYSBmZXcgZ3JhbmRmYXRo ZXJlZCB0YWdzIHRoYXQgc3RhcnQgd2l0aCAiaS0iIHRoYXQKICAgICAgYXJlIHZhbGlkKQoK ICAgICAgYXItYS1hYWEtYi1iYmItYS1jY2MgKHR3byBleHRlbnNpb25zIHdpdGggc2FtZSBz aW5nbGUtbGV0dGVyCiAgICAgIHByZWZpeCkKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMTUs IDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgNThdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA2CgoK QXV0aG9ycycgQWRkcmVzc2VzCgogICBBZGRpc29uIFBoaWxsaXBzIChlZGl0b3IpCiAgIFlh aG9vISBJbmMuCgogICBFbWFpbDogYWRkaXNvbkBpbnRlci1sb2NhbGUuY29tCiAgIFVSSTog ICBodHRwOi8vd3d3LmludGVyLWxvY2FsZS5jb20KCgogICBNYXJrIERhdmlzIChlZGl0b3Ip CiAgIEdvb2dsZQoKICAgRW1haWw6IG1hcmsuZGF2aXNAbWFjY2hpYXRvLmNvbSBvciBtYXJr LmRhdmlzQGdvb2dsZS5jb20KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAxNSwgMjAwNyAgICAg ICAgICAgICAgICBbUGFnZSA1OV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFu Z3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDYKCgpJbnRlbGxlY3R1 YWwgUHJvcGVydHkgU3RhdGVtZW50CgogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiBy ZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQogICBJbnRlbGxlY3R1YWwg UHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQg dG8KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNo bm9sb2d5IGRlc2NyaWJlZCBpbgogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8g d2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMKICAgbWlnaHQgb3IgbWlnaHQg bm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzCiAg IG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdo dHMuICBJbmZvcm1hdGlvbgogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8g cmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQg QkNQIDc5LgoKICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRG IFNlY3JldGFyaWF0IGFuZCBhbnkKICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBt YWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbgogICBhdHRlbXB0IG1hZGUgdG8g b2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YK ICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9m IHRoaXMKICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBv bi1saW5lIElQUiByZXBvc2l0b3J5IGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLgoK ICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBp dHMgYXR0ZW50aW9uIGFueQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBs aWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5CiAgIHJpZ2h0cyB0aGF0IG1heSBjb3Zl ciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudAogICB0aGlz IHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRG IGF0CiAgIGlldGYtaXByQGlldGYub3JnLgoKCkRpc2NsYWltZXIgb2YgVmFsaWRpdHkKCiAg IFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFy ZSBwcm92aWRlZCBvbiBhbgogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1Is IFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMKICAgT1IgSVMgU1BPTlNPUkVE IEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUCiAg IEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJF U1MgT1IgSU1QTElFRCwKICAgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FS UkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRQogICBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBO T1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRAogICBXQVJSQU5USUVTIE9G IE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4K CgpDb3B5cmlnaHQgU3RhdGVtZW50CgogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBT b2NpZXR5ICgyMDA2KS4gIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdAogICB0byB0aGUgcmln aHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFu ZAogICBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzIHJldGFpbiBh bGwgdGhlaXIgcmlnaHRzLgoKCkFja25vd2xlZGdtZW50CgogICBGdW5kaW5nIGZvciB0aGUg UkZDIEVkaXRvciBmdW5jdGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlCiAgIElu dGVybmV0IFNvY2lldHkuCgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBN YXJjaCAxNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSA2MF0KDAo= --------------020308070902060903090709 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --------------020308070902060903090709-- From ltru-bounces@ietf.org Mon Sep 11 14:38:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMqfo-0000ZE-6b; Mon, 11 Sep 2006 14:38:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMqfm-0000Z9-Tn for ltru@ietf.org; Mon, 11 Sep 2006 14:38:22 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMqfl-0001OL-IQ for ltru@ietf.org; Mon, 11 Sep 2006 14:38:22 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8BIcHsQ074139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Sep 2006 11:38:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=O74tOSX4ZPJJ0KBMMUa6pDqNGbgHu+5TGJwcE3v7wLVPHr+YUQTFJTXFyuV6Rkf6 Message-ID: <4505AD19.9080809@yahoo-inc.com> Date: Mon, 11 Sep 2006 11:38:17 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "'LTRU Working Group'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Ltru] diffs, changes, etc. X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org All, I just submitted draft-00 to the I-D editor. My home page is up-to-date, although I need to do some clean up. The HTML wdiff can be found by using this link: http://tinyurl.com/qtmag Changes: 1. The RFC Editor and AUTH48 changes for RFC 4646 have been incorped. 2. I added references to ISO 639-3. 3. I added rules for adding language and extlang tags to Section 3.4 (this was done this morning). I'm not married to these, but tried to incorporate extlangs according to discussion to date, as well as a special case for sign languages. 4. I removed text pertaining to the conversion from 3066 unless it was necessary for document understanding. 5. I changed the section discussing registry conversion rules substantially. In particular, I tried to remove all conversion rules and merely cited the new draft-initial, whatever that is, as the place to find these. I purposely avoided defining how the registry gets updated. Note that the reference to "4645bis" is not correct (of course). 6. I changed 'variant' validation along the lines I previously proposed, although I recognize that this is not a resolved issue. 7. I cut down the acknowledgments list. I will add names as I incorporate textual suggestions. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 17:31:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMtNF-0003Ir-IH; Mon, 11 Sep 2006 17:31:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMtNE-0003Im-MM for ltru@ietf.org; Mon, 11 Sep 2006 17:31:24 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMtNB-0000fd-Dd for ltru@ietf.org; Mon, 11 Sep 2006 17:31:24 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Mon, 11 Sep 2006 14:31:20 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 14:31:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Up-to-date copies of the LSR Date: Mon, 11 Sep 2006 14:30:28 -0700 Message-ID: In-Reply-To: <20060911174940.GE9240@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Up-to-date copies of the LSR thread-index: AcbVyqx/IcX94kbqTsydOft9w5TzaQAHo9Kg From: Peter Constable To: X-OriginalArrivalTime: 11 Sep 2006 21:31:14.0179 (UTC) FILETIME=[9BA18D30:01C6D5E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: John Cowan [mailto:cowan@ccil.org] > That will certainly work, but I can think of two simpler approaches, both > of which can be used concurrently, that strike me as just about as good: >=20 > 1) Provide the File-Date of the current registry as a separate resource > with its own URI as well as in the current registry resource. Then you > can pull the little resource and only pull the big one if warranted. >=20 > 2) If you are writing a client that does dynamic pulls, use the HTTP > If-Modified-Since: header to avoid pulling unchanged versions. What about providing delta files that can be used to patch a local copy of the LSR to incorporate changes made during some period, perhaps with new deltas provided on a regular (e.g. quarterly) basis? Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 17:55:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMtkh-000493-Gt; Mon, 11 Sep 2006 17:55:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMtkf-00046U-Ry for ltru@ietf.org; Mon, 11 Sep 2006 17:55:37 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMtke-0005Qv-LP for ltru@ietf.org; Mon, 11 Sep 2006 17:55:37 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GMtke-00067l-Br; Mon, 11 Sep 2006 17:55:36 -0400 Date: Mon, 11 Sep 2006 17:55:36 -0400 To: Peter Constable Subject: Re: [Ltru] Up-to-date copies of the LSR Message-ID: <20060911215536.GF9240@ccil.org> References: <20060911174940.GE9240@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: > What about providing delta files that can be used to patch a local copy > of the LSR to incorporate changes made during some period, perhaps with > new deltas provided on a regular (e.g. quarterly) basis? That was Addison's original suggestion; I was suggesting a compromise measure that just warns you when you need not pull. Frank's suggestion of using the HTTP HEAD method works too. -- John Cowan cowan@ccil.org http://ccil.org/~cowan The penguin geeks is happy / As under the waves they lark The closed-source geeks ain't happy / They sad cause they in the dark But geeks in the dark is lucky / They in for a worser treat One day when the Borg go belly-up / Guess who wind up on the street. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 18:18:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMu73-0004x7-T7; Mon, 11 Sep 2006 18:18:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMu72-0004wx-OS for ltru@ietf.org; Mon, 11 Sep 2006 18:18:44 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMu71-0003yb-EF for ltru@ietf.org; Mon, 11 Sep 2006 18:18:44 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8BMIRNO087479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Sep 2006 15:18:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=aRATPei+HtykeEXRd37VpLgjIZnaBcKMYnTG5pdk11EJGe5xOLNhm2WRzI+0uPOr Message-ID: <4505E0B3.2000802@yahoo-inc.com> Date: Mon, 11 Sep 2006 15:18:27 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Up-to-date copies of the LSR References: <20060911174940.GE9240@ccil.org> <20060911215536.GF9240@ccil.org> In-Reply-To: <20060911215536.GF9240@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > That was Addison's original suggestion; I was suggesting a compromise > measure that just warns you when you need not pull. Frank's suggestion > of using the HTTP HEAD method works too. > Documenting HEAD is a good idea, even if we were to do something else. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 11 20:25:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMw5c-0005Ay-4C; Mon, 11 Sep 2006 20:25:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMw5b-0005At-E1 for ltru@lists.ietf.org; Mon, 11 Sep 2006 20:25:23 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMw5R-0001hj-UL for ltru@lists.ietf.org; Mon, 11 Sep 2006 20:25:23 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GMw5M-0003He-W7 for ltru@lists.ietf.org; Tue, 12 Sep 2006 02:25:09 +0200 Received: from 212.82.251.156 ([212.82.251.156]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Sep 2006 02:25:08 +0200 Received: from nobody by 212.82.251.156 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Sep 2006 02:25:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 12 Sep 2006 02:16:31 +0200 Organization: Lines: 123 Message-ID: <4505FC5F.9D7@xyzzy.claranet.de> References: <4505AD19.9080809@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.156 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: Subject: [Ltru] Re: diffs, changes, etc. X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > http://tinyurl.com/qtmag Thanks, I just read it top down, some mostly minor points: --- (2.2.8) | Those that would not be well-formed according to the ABNF | in this document or that contain subtags that do not | individually appear in the registry are maintained in the | registry in record of the "grandfathered" type. s/record/records/. Maybe s/Those that/Other tags which/ plus s/or that contain/or contain/. When I first read 2.2.8 I hallucinated "Those tags" instead of "Those that", continuing the statement about "redundant". You could also split 2.2.8 in two paragraphs, the second paragraph about "grandfathered". --- 2.2.9: Right, that's the validation issue. Maybe we find a better example than es-Latn-CO-x-private for 4646bis. If the rules are changed as you want it the old example is complete overkill - and it's also unrelated to prefixes for variants. --- 3.1: Nit, why do we define a field-body in the ABNF, and later use field-value in the prose ? Apparently s/field-value/field-body/g is okay (there could be cases with multi-line bodies where a distinction is necessary, but not for 4646bis) --- 3.1, near "The field 'Deprecated' MAY" etc.: Please check why your spell-checker proposed to add a comma after "Usually" and after "In some historical cases". Apparently it also likes a serial comma (?) --- 3.1, "'Suppress-Script' MUST only appear in records whose 'Type' field-value is 'language'". Do we want to keep this as is, or allow Suppress-Script for extlang records ? If we keep it as is, are tags with extlang subtags supposed to inherit the Suppress-Script of the primary tag (if any) ? --- 3.3 s/[initial-registry]/[RFC 4645] and [4645bis]/ (?) Please strike the part about art-lobjan, it confuses me - especially where you talk about a hypothetical variant lobjan eligible for registration. --- Omigod, now I get it, are all those comma and s/which/that/ modifications Rfc-editor changes ? They should post a manual of style (or its URL). --- 3.4.3 | If a prefix is added to a record that does not contain the | same primary language subtag as an existing prefix, one | 'Comment' field per prefix SHOULD be added to record | explaining the different usages. Proposal (simplification): : If a prefix is added to a 'Variant' record, 'Comment' fields : SHOULD explain different usages per primary language subtag. It's only relevant for variants, and the SHOULD is only for different languages. Not if somebody adds say de-BE to 1996. --- 3.4.9 In essence that says "once an extlang-monster always an extlang-monster". IMO it should be allowed to deprecate the convoluted extlang-monsters in favour of new 639-1 or 639-2 codes as soon as they are available. This would also affect a MUST NOT in the "Preferred-Value" chapter, so that's a major point (but still compatible with 4646). --- 3.4.10 Same here. Let's get rid of extlang-monsters a.s.a.p. The MUST NOT about 'Preferred-Value' is anyway dubious: If a script "Flat" is deprecated recommending to use "Altn", then why should the registry not say so (in addition to noting this deprecation) ? --- 3.4.12: Related, replacing an extlang foo by a language foo is a good idea where possible, not a MUST NOT. The MUST NOT affects an unrelated foo (without replacing the extlang foo), and the opposite attempt, adding a new extlang foo where an ordinary language tag foo already exists (related or not). --- 3.5 Remove "reserved for future standardization. These subtags will be" (that results in ...subtags are REQUIRED...) | Note: The purpose of the "Description" in the registration | is to aid to people s/"Description"/"Reference"/ (this is unrelated to the field) s/to aid to/to aid/ --- 3.6 | The addition or maintenance of fields (generally of an | informational nature) in Tag or Subtag records as described | in Section 3.1 and subject to the stability provisions in | Section 3.4. This sentence no verb, s/as/is/ (?) --- 3.8 s/IANA SHALL/IANA is asked to/. Same procedure as last year, I don't like 2119-keywords while talking to IANA... :-) --- 5.1: Same here. I had completely forgotten how *_long_* this text actually is. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 00:24:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMzot-000534-3P; Tue, 12 Sep 2006 00:24:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMzos-00051b-0h for ltru@ietf.org; Tue, 12 Sep 2006 00:24:22 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMzop-000449-Mk for ltru@ietf.org; Tue, 12 Sep 2006 00:24:21 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060912042414.NUJI29000.mta13.adelphia.net@DGBP7M81>; Tue, 12 Sep 2006 00:24:14 -0400 Message-ID: <002501c6d623$4cca8ce0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <789E617C880666438EDEE30C2A3E8D10EEF1@mailsrvnt05.enet.sharplabs.com> Subject: Re: [Ltru] Re: Fw: RFC 4645 on Initial Language Subtag Registry Date: Mon, 11 Sep 2006 21:23:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org McDonald, Ira wrote: > My two cents - any 800-page I-D is BAD - publishing one is tantamount > to saying "don't bother to pay any attention to the output of this > WG". > > Squashing the registry format (which may change again in the > RFC464xbis era, perhaps?) into an I-D is an exercise that diverts > attention from the content of the prototype registry and issues with > that content. Well, we'd better decide this pretty soon since it's one of our deliverables, and I'm supposed to submit a first draft within the next 20 days. As long as Ira mentions the "format" -- we're also chartered to discuss possible "adjustments to... the form of the registry." Has anyone had any thoughts about that? Any news about the supposed plan to move all IANA registries to XML? Now is probably the best time to talk about this. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 00:53:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN0HF-00007R-PX; Tue, 12 Sep 2006 00:53:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN0HD-00007M-RF for ltru@lists.ietf.org; Tue, 12 Sep 2006 00:53:39 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN0HD-0001OS-8I for ltru@lists.ietf.org; Tue, 12 Sep 2006 00:53:39 -0400 Received: from [10.72.72.29] (snvvpn1-10-72-72-c29.corp.yahoo.com [10.72.72.29]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8C4rTM2002727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Sep 2006 21:53:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=IqoI6ayQ1bd26TWAiQFuBO/XDeF7aT7gqS4fczOAxdktYS4I7KzJDq+fgxCtbNuy Message-ID: <45063D49.6030202@yahoo-inc.com> Date: Mon, 11 Sep 2006 21:53:29 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: diffs, changes, etc. References: <4505AD19.9080809@yahoo-inc.com> <4505FC5F.9D7@xyzzy.claranet.de> In-Reply-To: <4505FC5F.9D7@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Thanks for the first substantial read-through. Comments follow. Frank Ellermann wrote: > > --- > (2.2.8) > | Those that would not be well-formed according to the ABNF > | in this document or that contain subtags that do not > | individually appear in the registry are maintained in the > | registry in record of the "grandfathered" type. > > s/record/records/. Good catch. Done. Maybe s/Those that/Other tags which/ plus > s/or that contain/or contain/. I made the first one "Of those tags, those that..." which makes the second one "Those tags that..." When I first read 2.2.8 I > hallucinated "Those tags" instead of "Those that", continuing > the statement about "redundant". You could also split 2.2.8 > in two paragraphs, the second paragraph about "grandfathered". I made the split. The rewrite above addresses weaknesses in both our eyes. > > --- > 2.2.9: Right, that's the validation issue. Maybe we find a > better example than es-Latn-CO-x-private for 4646bis. If the > rules are changed as you want it the old example is complete > overkill - and it's also unrelated to prefixes for variants. It could be a prefix for a variant. It is overkill, but it does illustrate the point completely. The main question is: validate prefixes or not? > > --- > 3.1: Nit, why do we define a field-body in the ABNF, and later > use field-value in the prose ? > > Apparently s/field-value/field-body/g is okay (there could be > cases with multi-line bodies where a distinction is necessary, > but not for 4646bis) Yuck. How did *that* slip by? Performed s/field-value/field-body/g > > --- > 3.1, near "The field 'Deprecated' MAY" etc.: Please check why > your spell-checker proposed to add a comma after "Usually" and > after "In some historical cases". Apparently it also likes a > serial comma (?) Heh heh heh. It's the insidious comma disease of the RFC Editor. It is correct, so it's here. They also like serial comma (I usually do too, but Harald didn't appear to) and have an allergy to colons (full and semi). The "which/that" mistakes are my fault entirely. > > --- > 3.1, "'Suppress-Script' MUST only appear in records whose > 'Type' field-value is 'language'". Do we want to keep this as > is, or allow Suppress-Script for extlang records ? If we keep > it as is, are tags with extlang subtags supposed to inherit the > Suppress-Script of the primary tag (if any) ? I kept this as is out of a certain kind of parsimony. The question is whether there is ever a case where 'xx' is written in more than one script but 'xx-yyy' or 'xx-yyy-zzz' is written customarily in one script---and we need to call it out. I think the answer is no, since Suppress-Script is a kludge for *existing* tag compatibility. Since there are no existing extlangs, they don't need the kludge :-). > > --- > 3.3 s/[initial-registry]/[RFC 4645] and [4645bis]/ (?) Please > strike the part about art-lobjan, it confuses me - especially > where you talk about a hypothetical variant lobjan eligible > for registration. I need to fix the 4645/4645bis references. I always thought the 'art-lojban' example referred to the first part of the sentence. It would be better to cite something like '-scouse' (although John Cowan is trying to exterminate our example!!). > > --- > Omigod, now I get it, are all those comma and s/which/that/ > modifications Rfc-editor changes ? They should post a manual > of style (or its URL). Bwah-ha-ha-ha. Yep. > > --- > 3.4.3 > | If a prefix is added to a record that does not contain the > | same primary language subtag as an existing prefix, one > | 'Comment' field per prefix SHOULD be added to record > | explaining the different usages. > > Proposal (simplification): > : If a prefix is added to a 'Variant' record, 'Comment' fields > : SHOULD explain different usages per primary language subtag. > > It's only relevant for variants, and the SHOULD is only for > different languages. Not if somebody adds say de-BE to 1996. :: shudder :: my text is impenetrable, no? I don't understand why you wouldn't want an explanation for longer prefixes though... especially for a mere recommendation. How about (very subtly different from yours): -- If a prefix is added to a variant record, Comment' fields SHOULD be used to explain different usages with the various prefixes. -- > > --- > 3.4.9 In essence that says "once an extlang-monster always an > extlang-monster". Yes. I'm following the idea that "one a canonical tag/always the canonical tag". > IMO it should be allowed to deprecate the > convoluted extlang-monsters in favour of new 639-1 or 639-2 > codes as soon as they are available. This would also affect a > MUST NOT in the "Preferred-Value" chapter, so that's a major > point (but still compatible with 4646). The problem is that ISO 639-2 might find a few tags that are "promoted" from ISO 639-3. If we have 'yue' enclosed by 'zh' today, we don't want to have "zh", "zh-yue" and "yue" being used interchangeably (as prefixes). Among other things, that breaks matching in particularly uncomfortable ways. > > --- > 3.4.10 Same here. Let's get rid of extlang-monsters a.s.a.p. The only way I see to do that is to prohibit them ex post facto. > > The MUST NOT about 'Preferred-Value' is anyway dubious: If a > script "Flat" is deprecated recommending to use "Altn", then > why should the registry not say so (in addition to noting this > deprecation) ? I'd be willing to consider deprecation of codes "best forgotten as mistakes". But not for recycling codes as various kinds of subtag. That's messy. > > --- > 3.4.12: Related, replacing an extlang foo by a language foo > is a good idea where possible, not a MUST NOT. The MUST NOT > affects an unrelated foo (without replacing the extlang foo), > and the opposite attempt, adding a new extlang foo where an > ordinary language tag foo already exists (related or not). Except 'foo' is not unrelated. Since 639-2 and 639-3 share a code space, 'foo' MUST have the same meaning in both. What this says is: you won't find "Foo-ese" with two different tag forms. It's xx-foo or it's foo. Period. We can and should debate this point. > > --- > 3.5 > Remove "reserved for future standardization. These subtags > will be" (that results in ...subtags are REQUIRED...) Good catch. I put: -- Extended language subtags MUST include exactly one 'Prefix' field. -- > > | Note: The purpose of the "Description" in the registration > | is to aid to people > s/"Description"/"Reference"/ (this is unrelated to the field) > s/to aid to/to aid/ I made the sentence: -- Note: The purpose of the "Reference to published description" section in the registration form is to aid in verifying whether a language is registered or what language or language variation a particular subtag refers to. -- > > --- > 3.6 > | The addition or maintenance of fields (generally of an > | informational nature) in Tag or Subtag records as described > | in Section 3.1 and subject to the stability provisions in > | Section 3.4. > > This sentence no verb, s/as/is/ (?) It's the formatting that's confusing here. Each bullet item dangles from the trailing "includes:" above the list. > > --- > 3.8 s/IANA SHALL/IANA is asked to/. Same procedure as last > year, I don't like 2119-keywords while talking to IANA... :-) Oddly, this is what we did last time. Still, making "SHALL" into "will" was easy enough. > --- > 5.1: Same here. Cleansed. > > I had completely forgotten how *_long_* this text actually is. And it lost several pages during this edit!! Thanks again, Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 01:42:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN12P-0006ZO-Og; Tue, 12 Sep 2006 01:42:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN12O-0006ZJ-Dl for ltru@ietf.org; Tue, 12 Sep 2006 01:42:24 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN12N-0008SR-54 for ltru@ietf.org; Tue, 12 Sep 2006 01:42:24 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060912054222.UTGF28624.mta11.adelphia.net@DGBP7M81> for ; Tue, 12 Sep 2006 01:42:22 -0400 Message-ID: <001401c6d62e$36f45620$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 11 Sep 2006 22:42:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [Ltru] Re: 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > As soon as I find out that there are more Ainu than the one I've heard > of before (which happens to be the JP Ainu) I better check what's > going on. The only ethnic group called Ainu that I'm aware of is the indigenous Japanese group, but there are two languages called Ainu, one spoken in Japan (and Russia) and the other in China. Ethnologue says there are 15 speakers of Ainu (Japan) and 6,570 speakers of Ainu (China). For whatever that's worth. >> When 639-3 changes a 639-2 name by adding a country name or the word >> "generic", replace the old Description with the new one. > > Slightly messy, because the registered 639-2 tag apparently isn't what > 639-3 considers as "generic". As a tag it has the semantics of their > "specific" code. Which isn't the registered tag. Now that's > confusing as soon as you try to talk about it. It does have the "generic" semantic, because 639-2 doesn't differentiate between (for example) "generic" Malay and "specific" Malay. > While "Malay is Malay (unless you want Ambonese etc.)" should be clear > for readers not interested in these subtleties. Actually "Malay, Ambonese" isn't one of the languages subsumed under the "Malay (generic)" macrolanguage. There are, however, 13 other "Malay" languages that are so subsumed, so your "unless" clause might get pretty long. >> Otherwise, add the new Description to the existing ones. That's a >> rule based on an obvious pattern. > > Yes, but I don't like its outcome. That wasn't part of the deal. :-) > Can we do this without the "otherwise" qualifier, simply add it always > as is ? For the few cases you found we don't need optimizations and > convoluted special rules. I thought you were the one who asked for a rule. OK, everyone: If we do what Frank wants, we will have: Type: language Subtag: ms Description: Malay Description: Malay (generic) Added: 2005-10-16 Suppress-Script: Latn ... Type: extlang Subtag: mly Description: Malay (specific) Added: xxxx-xx-xx Prefix: ms and also: Type: language Subtag: aib Description: Ainu (China) Added: xxxx-xx-xx ... Type: language Subtag: ain Description: Ainu Description: Ainu (Japan) Added: 2005-10-16 Is that what the group wants? -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 01:44:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN14h-0007NA-U9; Tue, 12 Sep 2006 01:44:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN14h-0007N5-EI for ltru@ietf.org; Tue, 12 Sep 2006 01:44:47 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN14g-00008n-75 for ltru@ietf.org; Tue, 12 Sep 2006 01:44:47 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060912054445.TFFD27224.mta10.adelphia.net@DGBP7M81> for ; Tue, 12 Sep 2006 01:44:45 -0400 Message-ID: <001801c6d62e$8c0f2400$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 11 Sep 2006 22:44:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ltru] Re: Comments that refer to "ISO codes" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > Do codes sometimes move from 639-3 to 639-2? In that case, it would > mean we have to update the comment, which looks like unnecessary work > to me. No, they're all part of the same code space. I retract this suggestion. It's not that big a deal. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 01:58:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN1I8-00033w-BP; Tue, 12 Sep 2006 01:58:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN1I7-00033r-43 for ltru@ietf.org; Tue, 12 Sep 2006 01:58:39 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN1I5-0002TV-TY for ltru@ietf.org; Tue, 12 Sep 2006 01:58:39 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060912055837.VBTC28624.mta11.adelphia.net@DGBP7M81> for ; Tue, 12 Sep 2006 01:58:37 -0400 Message-ID: <002001c6d630$7be53130$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 11 Sep 2006 22:58:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ltru] Extlangs or not? (was: Re: diffs, changes, etc.) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > 3.4.10 Same here. Let's get rid of extlang-monsters a.s.a.p. Please, group, let us decide NOW, once and for all, whether we are going to have extlangs or not. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 02:36:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN1sl-0006ZD-Tr; Tue, 12 Sep 2006 02:36:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN1sk-0006Z8-KP for ltru@lists.ietf.org; Tue, 12 Sep 2006 02:36:30 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN1sj-0005ne-4p for ltru@lists.ietf.org; Tue, 12 Sep 2006 02:36:30 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GN1sV-0006KE-Fh for ltru@lists.ietf.org; Tue, 12 Sep 2006 08:36:15 +0200 Received: from pd9fba901.dip0.t-ipconnect.de ([217.251.169.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Sep 2006 08:36:15 +0200 Received: from nobody by pd9fba901.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Sep 2006 08:36:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 12 Sep 2006 08:32:44 +0200 Organization: Lines: 107 Message-ID: <4506548C.4F54@xyzzy.claranet.de> References: <4505AD19.9080809@yahoo-inc.com> <4505FC5F.9D7@xyzzy.claranet.de> <45063D49.6030202@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba901.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: Subject: [Ltru] Re: diffs, changes, etc. X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >> --- >> 2.2.9: Right, that's the validation issue. Maybe we find a >> better example than es-Latn-CO-x-private for 4646bis. If >> the rules are changed as you want it the old example is >> complete overkill - and it's also unrelated to prefixes for >> variants. > It could be a prefix for a variant. It is overkill, but it > does illustrate the point completely. If we drop variant-validation let's better use a simple extlang example. And if we keep it let's use an example relevant for a variant and get rid of the -x-private part. > The main question is: validate prefixes or not? If we replace SHOULD by MUST elsewhere (eliminating generic variants) validating the prefixes is in theory possible. Like it's possible to validate extlang prefixes (with an obsolete copy of the registry it can fail). I'm not sure about this. --- > They also like serial comma (I usually do too, Me too, mainly because it's the only English comma rule I know. >> --- >> 3.1, "'Suppress-Script' MUST only appear in records whose >> 'Type' field-value is 'language'". Do we want to keep this >> as is, or allow Suppress-Script for extlang records ? If we >> keep it as is, are tags with extlang subtags supposed to >> inherit the Suppress-Script of the primary tag (if any) ? > I kept this as is out of a certain kind of parsimony. The > question is whether there is ever a case where 'xx' is > written in more than one script but 'xx-yyy' or 'xx-yyy-zzz' > is written customarily in one script---and we need to call > it out. > I think the answer is no, since Suppress-Script is a kludge > for *existing* tag compatibility. Since there are no existing > extlangs, they don't need the kludge :-). Plausible. And if 'xx' has a Suppress-Script, does this affect 'xx-yyy' ? Somewhere you have "add guidlines here" as an open question, that could be a point. --- >> 3.3 s/[initial-registry]/[RFC 4645] and [4645bis]/ (?) [...] > I need to fix the 4645/4645bis references. In 3.3 you apparently need both. > I always thought the 'art-lojban' example referred to the > first part of the sentence. It would be better to cite > something like '-scouse' (although John Cowan is trying to > exterminate our example!!). If it's gone we can't use it. For art-lobjan the language has now its own ordinary tag, therefore registering lobjan as a variant for that language (prefix) makes no sense. It could be used for an unrelated dialect of another language. I thought that's the point of this example. What's the real point, in what sense is lobjan "eligible to be registered" ? --- > I don't understand why you wouldn't want an explanation for > longer prefixes though... If it's interesting I want it. But that's no general SHOULD, > How about (very subtly different from yours): > -- > If a prefix is added to a variant record, Comment' fields > SHOULD be used to explain different usages with the various > prefixes. > -- Okay, now "different usages" is better visible, and the SHOULD won't justify to add "de-BE is used for German in BE" comments. --- > The problem is that ISO 639-2 might find a few tags that are > "promoted" from ISO 639-3. If we have 'yue' enclosed by 'zh' > today, we don't want to have "zh", "zh-yue" and "yue" being > used interchangeably (as prefixes). Among other things, that > breaks matching in particularly uncomfortable ways. On the other hand yue is shorter than zh-yue, and we mention "shortest" in another chapter. A strategy like "take 639-1, if that fails take 639-2 (plus details), and if it still fails take 639-3 (as extlang if necessary)" is simple. Adding steps "and verify if it's registered" wasn't necessary for 3066/4646. --- [MUST NOT Preferred-Value] > I'd be willing to consider deprecation of codes "best > forgotten as mistakes". But not for recycling codes Yes, cases like iw, where the registry offers he. The MUST NOT apparently says "this must never happen again", and that's IMO too optimistic for a zoo with several thousands new 639-3 tags. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 02:46:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN22a-0001Ky-H2; Tue, 12 Sep 2006 02:46:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN22Z-0001Kt-N3 for ltru@lists.ietf.org; Tue, 12 Sep 2006 02:46:39 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN22Y-0006hT-E4 for ltru@lists.ietf.org; Tue, 12 Sep 2006 02:46:39 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GN22O-000853-1G for ltru@lists.ietf.org; Tue, 12 Sep 2006 08:46:28 +0200 Received: from pd9fba901.dip0.t-ipconnect.de ([217.251.169.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Sep 2006 08:46:28 +0200 Received: from nobody by pd9fba901.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Sep 2006 08:46:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 12 Sep 2006 08:45:51 +0200 Organization: Lines: 17 Message-ID: <4506579F.56DE@xyzzy.claranet.de> References: <789E617C880666438EDEE30C2A3E8D10EEF1@mailsrvnt05.enet.sharplabs.com> <002501c6d623$4cca8ce0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba901.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Re: Fw: RFC 4645 on Initial Language Subtag Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > we're also chartered to discuss possible "adjustments to... > the form of the registry." Has anyone had any thoughts about > that? Yes, keep it as is, it's good enough. > Any news about the supposed plan to move all IANA registries > to XML? Was that on a Joint-W3C-Unicode-making-fun-of-the-IETF list ? The worst I've seen were proposals to use CharMapML, so far nobody supported that. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 02:49:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN25T-0002RI-E5; Tue, 12 Sep 2006 02:49:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN25R-0002Ox-LW for ltru@ietf.org; Tue, 12 Sep 2006 02:49:37 -0400 Received: from mta5.adelphia.net ([68.168.78.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN25Q-0006zC-D0 for ltru@ietf.org; Tue, 12 Sep 2006 02:49:37 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060912064821.RWQH29000.mta13.adelphia.net@DGBP7M81> for ; Tue, 12 Sep 2006 02:48:21 -0400 Message-ID: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 11 Sep 2006 23:48:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Ltru] Can't add a Preferred-Value to a redundant tag X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I've been working through the ISO 639-3 code elements for sign languages, converting them into extlang subtags and correlating them with the existing "sgn-XX" redundant tags, and have run into a problem. As I understand it, the plan is to deprecate the "sgn-XX" tags in favor of the new "sgn-xxx" language-extlang combinations, meaning that we would give "sgn-XX" a Preferred-Value of "sgn-xxx". (Remember that the Preferred-Value for a tag must be a tag, not a subtag.) However, according to Section 3.1 we cannot do this: The field 'Preferred-Value' MUST NOT be modified once created in the registry. The field MAY be added to records of type "grandfathered" and "region" according to the rules in Section 3.3. Otherwise the field MUST NOT be added to any record already in the registry. I don't know why we allowed grandfathered tags to be assigned a Preferred-Value at a later date, but did not allow the same for redundant tags. As a reminder, these 'sgn-XX" tags are the only redundant tags that were *already* redundant at the time they were registered under RFC 3066. The others contained script subtags, or some other components which were not allowable RFC 3066 subtags. We seem to have three options (using American Sign Language as our example): 1. Change the wording in Section 3.1 to allow redundant tags to be assigned a Preferred-Value. This way, "sgn-US" could be deprecated and assigned a Preferred-Value of "sgn-ase". The disadvantage is that there might have been a perfectly good reason for disallowing this in the first place. 2, Do not change the wording, and add "ase" as a deprecated-as-birth extlang subtag. We cannot assign it a Preferred-Value of "sgn-US" as we might like, since the P-V for any subtag must be a subtag of the same type. This would mean two tagging possibilities for the same Description, one of which would be deprecated but would not point to the other. 3. Do not change the wording, and do not add "ase" at all. The disadvantage of this is that coding for sign languages becomes haphazard; American Sign Language would be "sgn-US" but Cuban Sign Language would be "sgn-csf". We would have to justify which 639-3 sign languages are added on the basis of which redundant tags exist. Three guesses which solution I prefer. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 02:58:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN2Dl-0005Qj-JL; Tue, 12 Sep 2006 02:58:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN2Dk-0005OG-1A for ltru@lists.ietf.org; Tue, 12 Sep 2006 02:58:12 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN2Di-0007gQ-OD for ltru@lists.ietf.org; Tue, 12 Sep 2006 02:58:12 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GN2DX-0001vj-7l for ltru@lists.ietf.org; Tue, 12 Sep 2006 08:57:59 +0200 Received: from pd9fba901.dip0.t-ipconnect.de ([217.251.169.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Sep 2006 08:57:59 +0200 Received: from nobody by pd9fba901.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Sep 2006 08:57:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 12 Sep 2006 08:56:12 +0200 Organization: Lines: 15 Message-ID: <45065A0C.52FD@xyzzy.claranet.de> References: <002001c6d630$7be53130$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba901.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Ltru] Re: Extlangs or not? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: >> Let's get rid of extlang-monsters a.s.a.p. > Please, group, let us decide NOW, once and for all, whether > we are going to have extlangs or not. The comment above was about a case xy-uvw, where uvw is later added to 639-2. Addison's draft says "keep xy-uvw and ignore uvw" (first come, first served). I proposed "add uvw as new language tag, deprecate extlang uvw with Preferred-Value uvw" (shortest 639 tag wins). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 03:34:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN2mi-0000Qn-6Y; Tue, 12 Sep 2006 03:34:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN2mg-0000Qi-B8 for ltru@ietf.org; Tue, 12 Sep 2006 03:34:18 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN0eu-0004j5-4I for ltru@ietf.org; Tue, 12 Sep 2006 01:18:11 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060912051807.UGGT28624.mta11.adelphia.net@DGBP7M81> for ; Tue, 12 Sep 2006 01:18:07 -0400 Message-ID: <000e01c6d62a$d38c8510$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 11 Sep 2006 22:18:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Ltru] Re: ISO 639-3 description changes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> ... Therefore, I believe we should *replace* the existing (ISO >> 639-2-based) Description with the reference name from ISO 639-3. > > Here I disagree, let 639-2 replace it if necessary. If you insist on > it we can add a rule in 4646bis allowing the review list to remove > mainly redundant and potentially misleading descriptions based on > 639-2 individually at any time (in the 4645bis "date C" registry or at > registration time). I'd like to hear some additional voices on this. I know Debbie agrees with you. As always, I'm willing to be overruled if there is a group consensus. > It's very near to cherry picking, and users looking for the precise > description as published in 639-2 might be confused. Debbie mentioned > use cases where what you propose could remove identifiers (URNs or > similar) somewhere. I don't know what to do about this, or whether anyone is actually planning to correlate the Description fields precisely to the ISO standards. I know the ISO standards aren't correlated precisely to each other, or we wouldn't be having this discussion. > Weak analogoy: I could propose to replace by NAK in column > 2 of u+0015. Highly desirable from my POV, but the Unicode folks > would eat me alive, it breaks applications expecting in > column 2. The Unicode policy that the name of a character must never change (not merely its identity) has caused a lot of grief when a name turns out to be wrong, misleading, or even misspelled. Section 3.1 only says the Description is "a non-normative description of the subtag or tag." I worry that we will sacrifice clarity and usability to make the names, in essence, normative. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 05:18:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN4PV-0001Qu-Du; Tue, 12 Sep 2006 05:18:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN4PT-0001Ql-My for ltru@ietf.org; Tue, 12 Sep 2006 05:18:27 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN4PS-00083Q-EG for ltru@ietf.org; Tue, 12 Sep 2006 05:18:27 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id A14B226C110; Tue, 12 Sep 2006 11:18:09 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id B84E426C0D0; Tue, 12 Sep 2006 11:18:07 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id A807458ECFE; Tue, 12 Sep 2006 11:18:07 +0200 (CEST) Date: Tue, 12 Sep 2006 11:18:07 +0200 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20060912091807.GA17950@nic.fr> References: <789E617C880666438EDEE30C2A3E8D10EEF1@mailsrvnt05.enet.sharplabs.com> <002501c6d623$4cca8ce0$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002501c6d623$4cca8ce0$6401a8c0@DGBP7M81> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: LTRU Working Group Subject: [Ltru] Format of the registry (Was: RFC 4645 on Initial Language Subtag Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Mon, Sep 11, 2006 at 09:23:59PM -0700, Doug Ewell wrote a message of 32 lines which said: > As long as Ira mentions the "format" -- we're also chartered to > discuss possible "adjustments to... the form of the registry." Has > anyone had any thoughts about that? Before writing my parser, I preferred an XML format. Now that I have written a parser to the registry, I hesitate to continue to support a change which would destroy my work :-) > Any news about the supposed plan to move all IANA registries to XML? No idea. Do you mind if I ping the IANA about that? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 10:04:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN8sE-0006Y8-9k; Tue, 12 Sep 2006 10:04:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN8sC-0006Y2-Sb for ltru@ietf.org; Tue, 12 Sep 2006 10:04:24 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN8sB-0003j4-L3 for ltru@ietf.org; Tue, 12 Sep 2006 10:04:24 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060912140419.HYUS28624.mta11.adelphia.net@DGBP7M81>; Tue, 12 Sep 2006 10:04:19 -0400 Message-ID: <00b801c6d674$55d32850$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <789E617C880666438EDEE30C2A3E8D10EEF1@mailsrvnt05.enet.sharplabs.com> <002501c6d623$4cca8ce0$6401a8c0@DGBP7M81> <20060912091807.GA17950@nic.fr> Date: Tue, 12 Sep 2006 07:04:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Ltru] Re: Format of the registry (Was: RFC 4645 on Initial Language Subtag Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > Before writing my parser, I preferred an XML format. Now that I have > written a parser to the registry, I hesitate to continue to support a > change which would destroy my work :-) I'd have to change my program that converts the Registry into a DLL. That would be a fair amount of work, and I'm not looking forward to it, but we want whatever is best for the Registry and language tagging. >> Any news about the supposed plan to move all IANA registries to XML? > > No idea. Do you mind if I ping the IANA about that? That would be an excellent idea. Thanks in advance. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 11:50:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNAWP-0007YW-GC; Tue, 12 Sep 2006 11:50:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNAWN-0007YR-TB for ltru@ietf.org; Tue, 12 Sep 2006 11:49:59 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNAWM-0005CY-Hm for ltru@ietf.org; Tue, 12 Sep 2006 11:49:59 -0400 Received: from [10.72.72.29] (snvvpn1-10-72-72-c29.corp.yahoo.com [10.72.72.29]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8CFngHk021003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Sep 2006 08:49:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=SXa5wS5jJD00158cLRE99Xox7a6p7sGncXo23bPSiVEgpDTnJc9NKmb653zZApsP Message-ID: <4506D714.4020705@yahoo-inc.com> Date: Tue, 12 Sep 2006 08:49:40 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Can't add a Preferred-Value to a redundant tag References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> In-Reply-To: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > > I don't know why we allowed grandfathered tags to be assigned a > Preferred-Value at a later date, but did not allow the same for > redundant tags. Because redundant tags are, well, redundant. That is, "sgn-BE" will still be both "well-formed" and "valid" regardless of what we do with extlangs. In fact, it expresses an entirely different value than "sgn-bvs" does. One is "Belgian Sign Language", a specific language. The other is "sign language(s) as used in Belgium". > > 2, Do not change the wording, and add "ase" as a deprecated-as-birth > extlang subtag. We cannot assign it a Preferred-Value of "sgn-US" as we > might like, since the P-V for any subtag must be a subtag of the same > type. This would mean two tagging possibilities for the same > Description, one of which would be deprecated but would not point to the > other. We will have to decide about this particular point. > > 3. Do not change the wording, and do not add "ase" at all. The > disadvantage of this is that coding for sign languages becomes > haphazard; American Sign Language would be "sgn-US" but Cuban Sign > Language would be "sgn-csf". We would have to justify which 639-3 sign > languages are added on the basis of which redundant tags exist. I don't know about "justification". We have here a problem with a registered tag "arriving first". However... I do note that we have an out for the registered-but-outmoded stuff. We can change the Description field to reflect the more generic meaning (remember: *broadening* of meaning is allowed!). Thus: Tag: sgn-US Description: Sign Language as used in the USA Comments: originally registered for ASL. "sgn-ase" is recommended for that meaning. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 12:00:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNAgx-0003Qb-6c; Tue, 12 Sep 2006 12:00:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNAgv-0003QR-7f for ltru@lists.ietf.org; Tue, 12 Sep 2006 12:00:53 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNAgt-0006FB-S6 for ltru@lists.ietf.org; Tue, 12 Sep 2006 12:00:53 -0400 Received: from [10.72.72.29] (snvvpn1-10-72-72-c29.corp.yahoo.com [10.72.72.29]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8CG0ZuF026167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Sep 2006 09:00:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=MbC7Z+vZGDMohC7NrOM0bRfya1e8c5mk5QS1Q1wd0eWwWAcsNxyKiqR9hHfKujHE Message-ID: <4506D9A3.5020400@yahoo-inc.com> Date: Tue, 12 Sep 2006 09:00:35 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: Extlangs or not? References: <002001c6d630$7be53130$6401a8c0@DGBP7M81> <45065A0C.52FD@xyzzy.claranet.de> In-Reply-To: <45065A0C.52FD@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -14.9 (--------------) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > > > The comment above was about a case xy-uvw, where uvw is later > added to 639-2. Addison's draft says "keep xy-uvw and ignore > uvw" (first come, first served). I proposed "add uvw as new > language tag, deprecate extlang uvw with Preferred-Value uvw" > (shortest 639 tag wins). > The question in my mind is whether the ISO 639-2 designation causes the language to actually escape from its collective or macro-language. My guess is that it does not. In particular, I note that ISO 639-2 serves folks like librarians. At some point in time, all of the ISO 639-3 codes could escape from "639-3 gaol" for use in libraries. This won't have any effect at all on the language itself or our understanding of the language. It's just that 639-2 is a narrower profile than 639-3. Another point: I believe that assigning code 'uvw' in ISO 639-2 will NOT cause it to be removed from the ranks of the 639-3 codes. What Frank proposes would invalidate tags and implementations in the field and require newer implementations to map 'xyz-uvw' => 'uvw' during matching. I think this is a Bad Thing. I do support Frank in wanting the fewest extlangs possible. The rules as I've currently written them will most likely create quite extensive lists of them. It might be nice if we could cherry-pick somehow (that is, have mostly language subtags with very few extlangs), but any rules we would invent for that would be entirely arbitrary. The only non-arbitrary rule I can think of is: we only introduce "enclosing" languages for those that are already registered as such. That is: "zh" "sgn" Everything else is a language. Thoughts? Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 12:05:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNAlV-0004eZ-JD; Tue, 12 Sep 2006 12:05:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNAlU-0004eO-Du for ltru@lists.ietf.org; Tue, 12 Sep 2006 12:05:36 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNAlS-0006z9-A4 for ltru@lists.ietf.org; Tue, 12 Sep 2006 12:05:35 -0400 Received: from [10.72.72.29] (snvvpn1-10-72-72-c29.corp.yahoo.com [10.72.72.29]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8CG5QEq026360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Sep 2006 09:05:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=cmyLu3HK/hQe1j1piOZiq23Zp0+5r9/mErqE+yYWG3d7POMgpn2vYLrur/anvfiL Message-ID: <4506DAC6.4050009@yahoo-inc.com> Date: Tue, 12 Sep 2006 09:05:26 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: Fw: RFC 4645 on Initial Language Subtag Registry References: <789E617C880666438EDEE30C2A3E8D10EEF1@mailsrvnt05.enet.sharplabs.com> <002501c6d623$4cca8ce0$6401a8c0@DGBP7M81> <4506579F.56DE@xyzzy.claranet.de> In-Reply-To: <4506579F.56DE@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org >> we're also chartered to discuss possible "adjustments to... >> the form of the registry." Has anyone had any thoughts about >> that? > > Yes, keep it as is, it's good enough. +1 > >> Any news about the supposed plan to move all IANA registries >> to XML? > > Was that on a Joint-W3C-Unicode-making-fun-of-the-IETF list ? > (laughing) I don't think such a thing has happened, but talking to colleagues in one or another forum has certainly produces ample opportunity for eye rolling at our choice of record-jar (at least I can hide behind John Cowan when the topic is raised). However... that battle is *over* and we should not revisit it. The only change I would willingly support to the registry would be one declaring that it uses UTF-8 as an encoding (so we can deprecate use of the NCR format). No doubt IANA's servers can emit: Content-Type: text/plain;charset=UTF-8 Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 15:48:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNEFU-0007mm-43; Tue, 12 Sep 2006 15:48:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNEFT-0007mh-G3 for ltru@lists.ietf.org; Tue, 12 Sep 2006 15:48:47 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNEFN-0001dD-6R for ltru@lists.ietf.org; Tue, 12 Sep 2006 15:48:47 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GNEF1-0007UR-3c for ltru@lists.ietf.org; Tue, 12 Sep 2006 21:48:19 +0200 Received: from du-017a-128.access.de.clara.net ([213.221.75.128]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Sep 2006 21:48:19 +0200 Received: from nobody by du-017a-128.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Sep 2006 21:48:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 12 Sep 2006 21:47:18 +0200 Organization: Lines: 27 Message-ID: <45070EC6.26AE@xyzzy.claranet.de> References: <789E617C880666438EDEE30C2A3E8D10EEF1@mailsrvnt05.enet.sharplabs.com> <002501c6d623$4cca8ce0$6401a8c0@DGBP7M81> <4506579F.56DE@xyzzy.claranet.de> <4506DAC6.4050009@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-017a-128.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ltru] UTF-8 (was: Fw: RFC 4645 on Initial Language Subtag Registry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I can hide behind John Cowan when the topic is raised I also like the format, it's awk-friendly. If you post an updated draft record-jar-01 with the 4646 reference I could create a LTRU-to-XML awk script as an exercise. > The only change I would willingly support to the > registry would be one declaring that it uses UTF-8 as > an encoding Hm... :-( That would be an advantage for XML, I could change the encoding to say Latin-1 using NCRs for the rest. With plain text it's too easy to get such modifications wrong, or forget what the state of a modified file is. > No doubt IANA's servers can emit: > Content-Type: text/plain;charset=UTF-8 Sure. With a mandatory signature it wouldn't annoy me too much, but I need to convert it for my legacy tools. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 15:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNEHR-0000bx-1z; Tue, 12 Sep 2006 15:50:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNEHF-0000R2-K6; Tue, 12 Sep 2006 15:50:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNEHF-0001kH-HY; Tue, 12 Sep 2006 15:50:37 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GNEHA-0007xt-Fu; Tue, 12 Sep 2006 15:50:37 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 27D54175B2; Tue, 12 Sep 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GNEGf-0002Z6-O2; Tue, 12 Sep 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Sep 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-4646bis-00.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Tags for Identifying Languages Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-4646bis-00.txt Pages : 60 Date : 2006-9-12 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-4646bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-4646bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-9-12124208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-4646bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-4646bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-12124208.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@ietf.org Tue Sep 12 16:04:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNEUV-0000j6-4u; Tue, 12 Sep 2006 16:04:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNEUT-0000iq-IO for ltru@lists.ietf.org; Tue, 12 Sep 2006 16:04:17 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNEUS-0003qs-71 for ltru@lists.ietf.org; Tue, 12 Sep 2006 16:04:17 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8CK42mf036706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Sep 2006 13:04:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=skYPe8w4e/KhzkWaydxUeqm7dzLulrOSZ4N2saZuTQGfm/8lxnh116sBAdyeIYcx Message-ID: <450712B2.70104@yahoo-inc.com> Date: Tue, 12 Sep 2006 13:04:02 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] UTF-8 References: <789E617C880666438EDEE30C2A3E8D10EEF1@mailsrvnt05.enet.sharplabs.com> <002501c6d623$4cca8ce0$6401a8c0@DGBP7M81> <4506579F.56DE@xyzzy.claranet.de> <4506DAC6.4050009@yahoo-inc.com> <45070EC6.26AE@xyzzy.claranet.de> In-Reply-To: <45070EC6.26AE@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > > I also like the format, it's awk-friendly. If you post > an updated draft record-jar-01 with the 4646 reference > I could create a LTRU-to-XML awk script as an exercise. Yep. Actually, since record-jar-00 isn't submitted, when I get a few minutes I intend to clean it up and submit it as an individual submission. > >> The only change I would willingly support to the >> registry would be one declaring that it uses UTF-8 as >> an encoding > > Hm... :-( That would be an advantage for XML, I could > change the encoding to say Latin-1 using NCRs for the > rest. > > With plain text it's too easy to get such modifications > wrong, or forget what the state of a modified file is. Changing the encoding might break one or two implementations that expect ASCII-with-markup, but UTF-8 is far superior to markup, in my (biased, Unicadette) opinion, since it makes the file plain text in a well-known, well-declared, highly-desirable encoding. Actually, the hard part would be sending non-ASCII-bearing registrations to IANA. To ensure that the right code points are used, we might have to send them ASCII-with-NCRs and have IANA unescape those when constructing the file. Hmm... perhaps we should leave well enough alone. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 16:57:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNFJk-00037F-5s; Tue, 12 Sep 2006 16:57:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNFJj-000367-6d for ltru@lists.ietf.org; Tue, 12 Sep 2006 16:57:15 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNFJh-00032O-TJ for ltru@lists.ietf.org; Tue, 12 Sep 2006 16:57:15 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GNFJO-00056V-Lc for ltru@lists.ietf.org; Tue, 12 Sep 2006 22:56:54 +0200 Received: from du-017a-128.access.de.clara.net ([213.221.75.128]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Sep 2006 22:56:54 +0200 Received: from nobody by du-017a-128.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Sep 2006 22:56:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 12 Sep 2006 22:55:54 +0200 Organization: Lines: 34 Message-ID: <45071EDA.2197@xyzzy.claranet.de> References: <789E617C880666438EDEE30C2A3E8D10EEF1@mailsrvnt05.enet.sharplabs.com> <002501c6d623$4cca8ce0$6401a8c0@DGBP7M81> <4506579F.56DE@xyzzy.claranet.de> <4506DAC6.4050009@yahoo-inc.com> <45070EC6.26AE@xyzzy.claranet.de> <450712B2.70104@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-017a-128.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > record-jar-00 isn't submitted Oops, I found a -00pre at your site then. > UTF-8 is far superior to markup, in my (biased, Unicadette) > opinion, since it makes the file plain text in a well-known, > well-declared, highly-desirable encoding. Yes. Not the maximal Latin-1 compatibility IFF you're willing to spend up to 7 octets. But apparently the optimal encoding for maximal ASCII compatibility. > Actually, the hard part would be sending non-ASCII-bearing > registrations to IANA. To ensure that the right code points > are used, we might have to send them ASCII-with-NCRs and > have IANA unescape those when constructing the file. MIME allows to send UTF-8, that's not really hard. If IANA uses some obscure auto-conversions to windows-1252 they could (1) please disable this, or (2) get it as attachement. While you love Unicode for me MIME is the best standard I know. It has a few dark corners, but in practice and for simple tasks like send "modification / insert request to IANA" it's fine. > perhaps we should leave well enough alone. Yes, for other reasons like not annoying folks who implemented 4646 validators (probably there are many more than only Doug, Stephane, and you). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 23:05:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNL45-00026C-OS; Tue, 12 Sep 2006 23:05:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNL44-000263-Go for ltru@ietf.org; Tue, 12 Sep 2006 23:05:28 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNL43-0006B7-8r for ltru@ietf.org; Tue, 12 Sep 2006 23:05:28 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060913030522.IOZT28624.mta11.adelphia.net@DGBP7M81>; Tue, 12 Sep 2006 23:05:22 -0400 Message-ID: <004301c6d6e1$72276d50$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> <4506D714.4020705@yahoo-inc.com> Subject: Re: [Ltru] Can't add a Preferred-Value to a redundant tag Date: Tue, 12 Sep 2006 20:05:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >> I don't know why we allowed grandfathered tags to be assigned a >> Preferred-Value at a later date, but did not allow the same for >> redundant tags. > > Because redundant tags are, well, redundant. That is, "sgn-BE" will > still be both "well-formed" and "valid" regardless of what we do with > extlangs. In fact, it expresses an entirely different value than > "sgn-bvs" does. One is "Belgian Sign Language", a specific language. > The other is "sign language(s) as used in Belgium". That was my objection all along to this scheme. >> ... This would mean two tagging possibilities for the same >> Description, one of which would be deprecated but would not point to >> the other. > > We will have to decide about this particular point. I'd really prefer not to have any more deprecated-at-birth subtags than absolutely necessary. > However... I do note that we have an out for the > registered-but-outmoded stuff. We can change the Description field to > reflect the more generic meaning (remember: *broadening* of meaning is > allowed!). > > Thus: > > Tag: sgn-US > Description: Sign Language as used in the USA > Comments: originally registered for ASL. "sgn-ase" is recommended > for that meaning. I can live with that, notably because it doesn't require the Comments field to contain critical, normative information. I'd suggest spelling out "ASL" since we would be doing this for several entries: Comments: originally registered for American Sign Language; use "sgn-ase" instead Overall, though, if you can get the Reviewer to buy off on this approach, I am fine with it. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 12 23:54:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNLpw-0002FU-Fe; Tue, 12 Sep 2006 23:54:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNLpv-0002FP-Dw for ltru@ietf.org; Tue, 12 Sep 2006 23:54:55 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNLps-0002A5-51 for ltru@ietf.org; Tue, 12 Sep 2006 23:54:55 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.628.4; Tue, 12 Sep 2006 20:54:51 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Tue, 12 Sep 2006 20:54:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: 3066ter encompassed languages Date: Tue, 12 Sep 2006 20:54:08 -0700 Message-ID: In-Reply-To: <001401c6d62e$36f45620$6401a8c0@DGBP7M81> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: 3066ter encompassed languages thread-index: AcbWLlY06+g8zV2qQMahzxPZ3SMGLAAtSmCw References: <001401c6d62e$36f45620$6401a8c0@DGBP7M81> From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 13 Sep 2006 03:54:30.0543 (UTC) FILETIME=[50F1F9F0:01C6D6E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0706549860==" Errors-To: ltru-bounces@ietf.org --===============0706549860== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogRG91ZyBFd2VsbCBbbWFpbHRvOmRld2VsbEBhZGVscGhpYS5uZXRdIA0KDQo+IEl0IGRv ZXMgaGF2ZSB0aGUgImdlbmVyaWMiIHNlbWFudGljLCBiZWNhdXNlIDYzOS0yIGRvZXNuJ3QgZGlm ZmVyZW50aWF0ZSANCj4gYmV0d2VlbiAoZm9yIGV4YW1wbGUpICJnZW5lcmljIiBNYWxheSBhbmQg InNwZWNpZmljIiBNYWxheS4NCg0KQnR3LCBpZiB5b3UndmUgaGFkIGEgY2hhbmNlIHRvIHJlYWQg dGhlIEZESVMsIHlvdSdsbCBzZWUgdGhhdCAiKGdlbmVyaWMpIiBhbmQgIihzcGVjaWZpYykiIGFy ZSBubyBsb25nZXIgdGhlIGRpc3Rpbmd1aXNoaW5nIHF1YWxpZmllcnMgdGhhdCBhcmUgZ29pbmcg dG8gYmUgdXNlZC4gUmF0aGVyLCB0aGUgaW5kaXZpZHVhbCBsYW5ndWFnZSBoYXMgbm8gYWRkZWQg cXVhbGlmaWVyLCBhbmQgIihtYWNyb2xhbmd1YWdlKSIgZ2V0cyBhZGRlZCB0byB0aGUgbWFjcm9s YW5ndWFnZS4gU28sIGl0IHdvdWxkIGJlICJNYWxheSIgYW5kICJNYWxheSAobWFjcm9sYW5ndWFn ZSkiLg0KDQoNCj4gT0ssIGV2ZXJ5b25lOiBJZiB3ZSBkbyB3aGF0IEZyYW5rIHdhbnRzLCB3ZSB3 aWxsIGhhdmU6DQo+DQo+ICAgIFR5cGU6IGxhbmd1YWdlDQo+ICAgIFN1YnRhZzogbXMNCj4gICAg RGVzY3JpcHRpb246IE1hbGF5DQo+ICAgIERlc2NyaXB0aW9uOiBNYWxheSAoZ2VuZXJpYykNCg0K SSBkb24ndCBzZWUgYSBuZWVkIGZvciB0aGF0IGR1cGxpY2F0aW9uOyBhbmQgZ2l2ZW4gdGhhdCB3 aGF0IHdlJ2QgZW5kIHVwIHdpdGggcGVyIHRoZSBjaGFuZ2UgSSBtZW50aW9uZWQgYWJvdmUgaXMN Cg0KICAgIFR5cGU6IGxhbmd1YWdlDQogICAgU3VidGFnOiBtcw0KICAgIERlc2NyaXB0aW9uOiBN YWxheQ0KICAgIERlc2NyaXB0aW9uOiBNYWxheSAobWFjcm9sYW5ndWFnZSkNCiAgICBBZGRlZDog MjAwNS0xMC0xNg0KICAgIFN1cHByZXNzLVNjcmlwdDogTGF0bg0KICAgIC4uLg0KICAgIFR5cGU6 IGV4dGxhbmcNCiAgICBTdWJ0YWc6IG1seQ0KICAgIERlc2NyaXB0aW9uOiBNYWxheQ0KICAgIEFk ZGVkOiB4eHh4LXh4LXh4DQogICAgUHJlZml4OiBtcw0KDQpJIGRvbid0IHBhcnRpY3VsYXJseSBj YXJlIGZvciBoYXZpbmcgdGhlIHNhbWUgZGVzY3JpcHRpb24gc2hvdyB1cCBpbiB0d28gZGlmZmVy ZW50IGVudHJpZXMgZm9yIHRoaW5ncyB0aGF0IGhhdmUgZGlmZmVyZW50IG1lYW5pbmdzLg0KDQoN ClBldGVyIENvbnN0YWJsZQ0K --===============0706549860== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0706549860==-- From ltru-bounces@ietf.org Wed Sep 13 00:05:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNM0R-00064Y-32; Wed, 13 Sep 2006 00:05:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNM0P-00064Q-Fe for ltru@ietf.org; Wed, 13 Sep 2006 00:05:45 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNM0O-0003KP-79 for ltru@ietf.org; Wed, 13 Sep 2006 00:05:45 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060913040539.MQTI27224.mta10.adelphia.net@DGBP7M81>; Wed, 13 Sep 2006 00:05:39 -0400 Message-ID: <005b01c6d6e9$dde9f820$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 12 Sep 2006 21:05:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Frank Ellermann Subject: [Ltru] Re: Extlangs or not? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I do support Frank in wanting the fewest extlangs possible. The rules > as I've currently written them will most likely create quite extensive > lists of them. I count 478 extlangs (including 124 sign languages) along with 7,195 primary languages. Put another way, there will tentatively be 15 times as many primary language subtags as extlangs. The 478 extlangs have 53 different Prefix values, an average of 9 possible extlangs per macrolanguage. Obviously this is skewed by the sign languages. > It might be nice if we could cherry-pick somehow (that is, have mostly > language subtags with very few extlangs), but any rules we would > invent for that would be entirely arbitrary. Cherry-picking = bad. Arbitrary = bad. Not only is this bad in and of itself, it could also cause us problems during IETF Last Call and on appeals. > The only non-arbitrary rule I can think of is: we only introduce > "enclosing" languages for those that are already registered as such. > That is: > > "zh" > "sgn" > > Everything else is a language. This is much too arbitrary. Don't do it. > Thoughts? Yes, I have a thought. We need to stop inventing things and then immediately declaring them Bad and Deprecated and To Be Avoided. Unicode has established a pattern of that for years, with CGJ and Plane 14 tag characters and annotation characters and the Private Use Area, and it doesn't necessarily present the best image of stability and thoughtful design. Here in LTRU we have invented the concept of extended language subtags, allowed up to three of them at a time in the syntax, and now we are trying to find ways to minimize or eliminate them. We went out of our way to specify that the Description field was non-normative (among many other caveats in Section 3.1) and now we can't even change them for fear of breaking some unknown process that might rely on their stability. We need to start embracing our own inventions, or else taking a more careful look before inventing. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 00:15:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNM9Y-0001Lc-P6; Wed, 13 Sep 2006 00:15:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNM9Y-0001JS-0d for ltru@ietf.org; Wed, 13 Sep 2006 00:15:12 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNM9V-0006L2-Qh for ltru@ietf.org; Wed, 13 Sep 2006 00:15:11 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GNM9V-00015L-GJ; Wed, 13 Sep 2006 00:15:09 -0400 Date: Wed, 13 Sep 2006 00:15:09 -0400 To: Peter Constable Subject: Re: [Ltru] Re: 3066ter encompassed languages Message-ID: <20060913041509.GD10145@ccil.org> References: <001401c6d62e$36f45620$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: > I don't particularly care for having the same description show up in > two different entries for things that have different meanings. +1 -- Why are well-meaning Westerners so concerned that John Cowan the opening of a Colonel Sanders in Beijing means cowan@ccil.org the end of Chinese culture? [...] We have had http://www.ccil.org/~cowan Chinese restaurants in America for over a century, and it hasn't made us Chinese. On the contrary, we obliged the Chinese to invent chop suey. --Marshall Sahlins _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 00:24:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNMIb-0004ai-3E; Wed, 13 Sep 2006 00:24:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNMIa-0004ac-2C for ltru@ietf.org; Wed, 13 Sep 2006 00:24:32 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNMIY-0007j5-R4 for ltru@ietf.org; Wed, 13 Sep 2006 00:24:32 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GNMIV-000280-OX; Wed, 13 Sep 2006 00:24:27 -0400 Date: Wed, 13 Sep 2006 00:24:27 -0400 To: Addison Phillips Subject: Re: [Ltru] Can't add a Preferred-Value to a redundant tag Message-ID: <20060913042427.GE10145@ccil.org> References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> <4506D714.4020705@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4506D714.4020705@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Because redundant tags are, well, redundant. That is, "sgn-BE" will > still be both "well-formed" and "valid" regardless of what we do with > extlangs. In fact, it expresses an entirely different value than > "sgn-bvs" does. One is "Belgian Sign Language", a specific language. The > other is "sign language(s) as used in Belgium". Actually, it doesn't. If you go back to RFC 3066, it specifically allows ietf-languages to register tags like "sgn-BE" that look compositional but don't mean what they say. Paragraph 2 of section 3: This procedure MAY also be used to register information with the IANA about a tag defined by this document, for instance if one wishes to make publicly available a reference to the definition for a language such as sgn-US (American Sign Language). So RFC 3066 and its registry between them explicitly say that sgn-US does not mean "sign languages spoken in the US", but the specific language called "American Sign Language" (which, BTW, is also used in Canada and perhaps elsewhere). Due to grandfathering, this is still true under RFC 4646. Since "sgn-US" does not have compositional meaning, by deprecating it in favor of "sgn-ase" we free it up to mean what it appears to mean. > Tag: sgn-US > Description: Sign Language as used in the USA > Comments: originally registered for ASL. "sgn-ase" is recommended > for that meaning. That's as much as to say the original meaning is deprecated. So let's say so openly, and supply the new tag for that meaning using the mechanism designed for that, namely Preferred-Value. -- John Cowan http://www.ccil.org/~cowan But no living man am I! You look upon a woman. Eowyn I am, Eomund's daughter. You stand between me and my lord and kin. Begone, if you be not deathless. For living or dark undead, I will smite you if you touch him. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 00:27:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNML5-000560-42; Wed, 13 Sep 2006 00:27:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNML3-00055v-Tj for ltru@lists.ietf.org; Wed, 13 Sep 2006 00:27:05 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNML2-0007sm-Jr for ltru@lists.ietf.org; Wed, 13 Sep 2006 00:27:05 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Tue, 12 Sep 2006 21:27:04 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Sep 2006 21:09:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 x-cr-puzzleid: {7D49B72F-2C51-45B9-95E1-8AAA837C5D55} Content-Class: urn:content-classes:message x-cr-hashedpuzzle: rYE= APKg AU74 AeA1 AzCd A4o/ BI+Z BaNC BcFc BjmK Bz06 CAUZ Cp/9 DVZx H8kS J+Pi; 1; bAB0AHIAdQBAAGwAaQBzAHQAcwAuAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {7D49B72F-2C51-45B9-95E1-8AAA837C5D55}; cABlAHQAZQByAGMAbwBuAEAAbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQA=; Wed, 13 Sep 2006 04:08:48 GMT; UgBFADoAIABbAEwAdAByAHUAXQAgAFIAZQA6ACAARQB4AHQAbABhAG4AZwBzACAAbwByACAAbgBvAHQAPwA= Subject: RE: [Ltru] Re: Extlangs or not? Date: Tue, 12 Sep 2006 21:08:48 -0700 Message-ID: In-Reply-To: <4506D9A3.5020400@yahoo-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Extlangs or not? thread-index: AcbWhKeAE+GkDrH5RWaIjd48SNnGSgAY83mQ References: <002001c6d630$7be53130$6401a8c0@DGBP7M81><45065A0C.52FD@xyzzy.claranet.de> <4506D9A3.5020400@yahoo-inc.com> From: Peter Constable To: X-OriginalArrivalTime: 13 Sep 2006 04:09:49.0085 (UTC) FILETIME=[74705CD0:01C6D6EA] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0170072869==" Errors-To: ltru-bounces@ietf.org --===============0170072869== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Class: urn:content-classes:message RnJvbTogQWRkaXNvbiBQaGlsbGlwcyBbbWFpbHRvOmFkZGlzb25AeWFob28taW5jLmNvbV0gDQoN Cj4gSW4gcGFydGljdWxhciwgSSBub3RlIHRoYXQgSVNPIDYzOS0yIHNlcnZlcyBmb2xrcyBsaWtl IGxpYnJhcmlhbnMuIEF0IA0KPiBzb21lIHBvaW50IGluIHRpbWUsIGFsbCBvZiB0aGUgSVNPIDYz OS0zIGNvZGVzIGNvdWxkIGVzY2FwZSBmcm9tICI2MzktMyANCj4gZ2FvbCIgZm9yIHVzZSBpbiBs aWJyYXJpZXMuIFRoaXMgd29uJ3QgaGF2ZSBhbnkgZWZmZWN0IGF0IGFsbCBvbiB0aGUgDQo+IGxh bmd1YWdlIGl0c2VsZiBvciBvdXIgdW5kZXJzdGFuZGluZyBvZiB0aGUgbGFuZ3VhZ2UuIEl0J3Mg anVzdCB0aGF0IA0KPiA2MzktMiBpcyBhIG5hcnJvd2VyIHByb2ZpbGUgdGhhbiA2MzktMy4NCg0K SXQncyBub3QgYXBwcm9wcmlhdGUgdG8gdGhpbmsgaW4gdGVybXMgb2YgIjYzOS0zIGdhb2wiOyBp dCBpcyBhYnNvbHV0ZWx5IGFwcHJvcHJpYXRlIHRvIHRoaW5rIGluIHRlcm1zIG9mICI2MzktMiBp cyBhIG5hcnJvd2VyIHByb2ZpbGUgdGhhbiA2MzktMyIuDQoNCkl0J3Mgb25lIGNvZGUgc3BhY2Uu IFRoZSBzZXQgb2YgYWxwaGEtMyBJRHMgZm9yIGNvbGxlY3Rpb25zIHdpbGwgYmUgbGlzdGVkIGlu IDYzOS01OyB0aGUgc2V0IG9mIGFscGhhLTMgSURzIGZvciBpbmRpdmlkdWFsIGxhbmd1YWdlcyBh bmQgbWFjcm9sYW5ndWFnZXMgd2lsbCBiZSBsaXN0ZWQgaW4gNjM5LTMuIEEgc3Vic2V0IG9mIHRo ZXNlIG9mIGNvbnNpZGVyZWQgdG8gYmUgb2YgaW50ZXJlc3QgdG8gcGFydGljdWxhciB1c2VyIGNv bW11bml0aWVzIHdpbGwgYmUgZGVsaW5lYXRlZCBpbiA2MzktMi4NCg0KSXQncyBlbnRpcmVseSBw b3NzaWJsZSB0aGF0IGF0IHNvbWUgcG9pbnQgaW4gdGhlIGZ1dHVyZSB0aGUgZXhpc3RpbmcgcGFy dHMgNjM5LXggd2lsbCBnbyBhd2F5LCBhbmQgdGhhdCB0aGVyZSB3aWxsIGJlIG9uZSBwdWJsaXNo ZWQgc3RhbmRhcmQgZm9yIGFscGhhLTMgSURzIHdpdGggb25lIG9yIG1vcmUgInByb2ZpbGVzIiAo aS5lLiwgc3Vic2V0cykgZGVmaW5lZCBmb3IgdXNlIGluIHBhcnRpY3VsYXIgYXBwbGljYXRpb25z LiBBdCB0aGF0IHBvaW50IGluIHRpbWUsIHRoZSBxdWVzdGlvbnMgYmVpbmcgYXNrZWQgaGVyZSBh Ym91dCB3aGV0aGVyIHRvIHVzZSBkZXNjcmlwdGlvbnMgZnJvbSBwYXJ0IDIgb3IgcGFydCAzIHdp bGwgYmUgbWVhbmluZ2xlc3M6IHRoZXJlIHdpbGwgYmUgb25seSBvbmUgc3RhbmRhcmQuDQoNCg0K DQo+IEFub3RoZXIgcG9pbnQ6IEkgYmVsaWV2ZSB0aGF0IGFzc2lnbmluZyBjb2RlICd1dncnIGlu IElTTyA2MzktMiB3aWxsIE5PVCANCj4gY2F1c2UgaXQgdG8gYmUgcmVtb3ZlZCBmcm9tIHRoZSBy YW5rcyBvZiB0aGUgNjM5LTMgY29kZXMuDQoNClRoYXQgaXMgbW9yZSB0aGFuIGEgYmVsaWVmOyBp dCBpcyBmYWN0Lg0KDQoNCj4gSSBkbyBzdXBwb3J0IEZyYW5rIGluIHdhbnRpbmcgdGhlIGZld2Vz dCBleHRsYW5ncyBwb3NzaWJsZS4gVGhlIHJ1bGVzIGFzIA0KPiBJJ3ZlIGN1cnJlbnRseSB3cml0 dGVuIHRoZW0gd2lsbCBtb3N0IGxpa2VseSBjcmVhdGUgcXVpdGUgZXh0ZW5zaXZlIA0KPiBsaXN0 cyBvZiB0aGVtLiBJdCBtaWdodCBiZSBuaWNlIGlmIHdlIGNvdWxkIGNoZXJyeS1waWNrIHNvbWVo b3cgKHRoYXQgDQo+IGlzLCBoYXZlIG1vc3RseSBsYW5ndWFnZSBzdWJ0YWdzIHdpdGggdmVyeSBm ZXcgZXh0bGFuZ3MpLCBidXQgYW55IHJ1bGVzIA0KPiB3ZSB3b3VsZCBpbnZlbnQgZm9yIHRoYXQg d291bGQgYmUgZW50aXJlbHkgYXJiaXRyYXJ5Lg0KDQpJIGRvbid0IGtub3cgd2h5IGFueWJvZHkg aGFzIGEgcHJvYmxlbSB3aXRoIGV4dGxhbmdzLiBJIGRvbid0IGV4cGVjdCBhIGxvdCBvZiBleHRs YW5ncyB3aWxsIG9jY3VyIGluIHRoZSB3aWxkOiB0aGV5IGNhbiBvbmx5IGV4aXN0IGluIGNhc2Vz IGxpa2UgemggYW5kIGFyIHdoZXJlIHRoZSBtYWpvcml0eSBvZiBjb250ZW50IGJ5IGZhciB3aWxs IHVzZSB0aGUgbWFjcm9sYW5ndWFnZSBJRCBhbmQgbm90aGluZyBtb3JlIGJlY2F1c2UgdGhlIG1h Y3JvbGFuZ3VhZ2UgSUQgaXMgYWxyZWFkeSB3aWRlbHkgdXNlZC4gS2VlcCBpbiBtaW5kIHRoZSB3 aG9sZSBwb2ludCBvZiB0aGUgbm90aW9uIG9mIG1hY3JvbGFuZ3VhZ2VzOiB0aGUgY29sbGVjdGl2 ZSBnZXRzIHJlZmVycmVkIHRvIGluIGV4aXN0aW5nIGFwcGxpY2F0aW9ucyBhcyB0aG91Z2ggaXRz IG9uZSBsYW5ndWFnZSB3aGlsZSBnYXVnZWQgYnkgb3RoZXIgbWVhc3VyZXMgaXRzIG11bHRpcGxl IGxhbmd1YWdlcy4gV2Ugb3VnaHQgdG8gd2FudCBhIG1hdGNoaW5nIHJlbGF0aW9uc2hpcCB0byBl eGlzdCBpbiB0aGVzZSBjYXNlczsgZXh0bGFuZ3MgZ2l2ZSB1cyB0aGF0IHdpdGggbm8gYWRkaXRp b25hbCBtYWNoaW5lcnkuDQoNCg0KDQpQZXRlciBDb25zdGFibGUNCg== --===============0170072869== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0170072869==-- From ltru-bounces@ietf.org Wed Sep 13 00:28:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNMM5-0005f3-CK; Wed, 13 Sep 2006 00:28:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNMM4-0005ey-2y for ltru@ietf.org; Wed, 13 Sep 2006 00:28:08 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNMM2-0007vq-TU for ltru@ietf.org; Wed, 13 Sep 2006 00:28:08 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GNMM2-0002Db-Mq; Wed, 13 Sep 2006 00:28:06 -0400 Date: Wed, 13 Sep 2006 00:28:06 -0400 To: Addison Phillips Subject: Re: [Ltru] Re: Extlangs or not? Message-ID: <20060913042806.GF10145@ccil.org> References: <002001c6d630$7be53130$6401a8c0@DGBP7M81> <45065A0C.52FD@xyzzy.claranet.de> <4506D9A3.5020400@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4506D9A3.5020400@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > The only non-arbitrary rule I can think of is: we only introduce > "enclosing" languages for those that are already registered as such. > That is: > > "zh" > "sgn" > > Everything else is a language. That rule is very arbitrary; it arbitrarily says that due to an accident of history you can use "zh" to mean "any kind of Chinese" but you cannot use "my" for "any kind of Malay", although the facts on the ground are exactly parallel. Instead, to deal reliably with Malay you must be aware of a whole bunch of syntactically unrelated tags. -- Only do what only you can do. John Cowan --Edsger W. Dijkstra's advice to a student in search of a thesis _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 01:06:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNMxH-0001y2-Aq; Wed, 13 Sep 2006 01:06:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNMxG-0001xw-A2 for ltru@ietf.org; Wed, 13 Sep 2006 01:06:34 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNMxB-0002jZ-1M for ltru@ietf.org; Wed, 13 Sep 2006 01:06:34 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060913050621.OLLU27224.mta10.adelphia.net@DGBP7M81> for ; Wed, 13 Sep 2006 01:06:21 -0400 Message-ID: <008401c6d6f2$5930adf0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 12 Sep 2006 22:06:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Ltru] Re: 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > Btw, if you've had a chance to read the FDIS, you'll see that > "(generic)" and "(specific)" are no longer the distinguishing > qualifiers that are going to be used. Rather, the individual language > has no added qualifier, and "(macrolanguage)" gets added to the > macrolanguage. So, it would be "Malay" and "Malay (macrolanguage)". I had not seen this. You may need to remind me of the URL where the document can be found. I dearly wish the downloadable tables (http://www.sil.org/iso639-3/download.asp) would be updated to reflect the changes you have described. >> OK, everyone: If we do what Frank wants, we will have: >> >> Type: language >> Subtag: ms >> Description: Malay >> Description: Malay (generic) > > I don't see a need for that duplication; and given that what we'd end > up with per the change I mentioned above is > > Type: language > Subtag: ms > Description: Malay > Description: Malay (macrolanguage) > Added: 2005-10-16 > Suppress-Script: Latn > ... > Type: extlang > Subtag: mly > Description: Malay > Added: xxxx-xx-xx > Prefix: ms > > I don't particularly care for having the same description show up in > two different entries for things that have different meanings. +1. Actually, this makes the confusion even worse if we have to keep the 639-2 name, because now there will be TWO subtags called simply "Malay" without qualification. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 01:27:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNNHU-00016K-RZ; Wed, 13 Sep 2006 01:27:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNNHT-00016E-9A for ltru@ietf.org; Wed, 13 Sep 2006 01:27:27 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNNHQ-0005pJ-Fn for ltru@ietf.org; Wed, 13 Sep 2006 01:27:27 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GNNHQ-0006DC-6Y; Wed, 13 Sep 2006 01:27:24 -0400 Date: Wed, 13 Sep 2006 01:27:24 -0400 To: Doug Ewell Subject: Re: [Ltru] Can't add a Preferred-Value to a redundant tag Message-ID: <20060913052724.GG10145@ccil.org> References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > 1. Change the wording in Section 3.1 to allow redundant tags to be > assigned a Preferred-Value. This way, "sgn-US" could be deprecated and > assigned a Preferred-Value of "sgn-ase". The disadvantage is that there > might have been a perfectly good reason for disallowing this in the > first place. +1 -- John Cowan cowan@ccil.org http://ccil.org/~cowan Big as a house, much bigger than a house, it looked to [Sam], a grey-clad moving hill. Fear and wonder, maybe, enlarged him in the hobbit's eyes, but the Mumak of Harad was indeed a beast of vast bulk, and the like of him does not walk now in Middle-earth; his kin that live still in latter days are but memories of his girth and his majesty. --"Of Herbs and Stewed Rabbit" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 01:57:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNNkX-0003jR-P9; Wed, 13 Sep 2006 01:57:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNNkX-0003ha-5b for ltru@ietf.org; Wed, 13 Sep 2006 01:57:29 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNNkT-0002AA-Sz for ltru@ietf.org; Wed, 13 Sep 2006 01:57:29 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GNNkT-0007im-9W; Wed, 13 Sep 2006 01:57:25 -0400 Date: Wed, 13 Sep 2006 01:57:25 -0400 To: Addison Phillips Subject: Re: [Ltru] Re: diffs, changes, etc. Message-ID: <20060913055725.GH10145@ccil.org> References: <4505AD19.9080809@yahoo-inc.com> <4505FC5F.9D7@xyzzy.claranet.de> <45063D49.6030202@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45063D49.6030202@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Heh heh heh. It's the insidious comma disease of the RFC Editor. It is > correct, so it's here. They also like serial comma (I usually do too, > but Harald didn't appear to) and have an allergy to colons (full and > semi). The "which/that" mistakes are my fault entirely. Leaving out serial commas can cause dreadful ambiguities: I dedicate this thesis to my parents, Ayn Rand[,] and God. Putting them in can never hurt. But as for the supposed which/that rule, it does not exist except in the fantasies of "usage" book authors who copy it from their predecessors. See: http://itre.cis.upenn.edu/~myl/languagelog/archives/000918.html http://itre.cis.upenn.edu/%7Emyl/languagelog/archives/001464.html http://itre.cis.upenn.edu/~myl/languagelog/archives/001467.html http://itre.cis.upenn.edu/%7Emyl/languagelog/archives/002189.html http://itre.cis.upenn.edu/~myl/languagelog/archives/002205.html and many others. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Original line from The Warrior's Apprentice by Lois McMaster Bujold: "Only on Barrayar would pulling a loaded needler start a stampede toward one." English-to-Russian-to-English mangling thereof: "Only on Barrayar you risk to lose support instead of finding it when you threat with the charged weapon." _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 09:20:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNUei-0000oM-1l; Wed, 13 Sep 2006 09:19:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNUeh-0000mb-Ci for ltru@ietf.org; Wed, 13 Sep 2006 09:19:55 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNUeg-0008CO-5T for ltru@ietf.org; Wed, 13 Sep 2006 09:19:55 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060913131953.ZUBS27224.mta10.adelphia.net@DGBP7M81> for ; Wed, 13 Sep 2006 09:19:53 -0400 Message-ID: <002601c6d737$4ad2f430$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Wed, 13 Sep 2006 06:19:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ltru] Re: Can't add a Preferred-Value to a redundant tag X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >> Tag: sgn-US >> Description: Sign Language as used in the USA >> Comments: originally registered for ASL. "sgn-ase" is >> recommended for that meaning. > > That's as much as to say the original meaning is deprecated. So let's > say so openly, and supply the new tag for that meaning using the > mechanism designed for that, namely Preferred-Value. To clarify: I greatly prefer this solution, whereby if we want to recommend one tagging solution over another, we use the Deprecated and Preferred-Value fields invented for that purpose. But if this is unacceptable to Addison and others for some reason, I can live with the Comments approach. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 09:21:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNUgS-00027g-JZ; Wed, 13 Sep 2006 09:21:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNUgQ-00027W-Ss for ltru@ietf.org; Wed, 13 Sep 2006 09:21:42 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNUgP-0008Tm-Ld for ltru@ietf.org; Wed, 13 Sep 2006 09:21:42 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060913132140.XBLY28624.mta11.adelphia.net@DGBP7M81> for ; Wed, 13 Sep 2006 09:21:40 -0400 Message-ID: <002a01c6d737$8b137880$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Wed, 13 Sep 2006 06:21:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] Re: Extlangs or not? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > I don't know why anybody has a problem with extlangs. I don't expect a > lot of extlangs will occur in the wild: they can only exist in cases > like zh and ar where the majority of content by far will use the > macrolanguage ID and nothing more because the macrolanguage ID is > already widely used. Keep in mind the whole point of the notion of > macrolanguages: the collective gets referred to in existing > applications as though its one language while gauged by other measures > its multiple languages. We ought to want a matching relationship to > exist in these cases; extlangs give us that with no additional > machinery. +1 -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 09:51:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNV95-0004ZD-7B; Wed, 13 Sep 2006 09:51:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNV93-0004Z8-US for ltru@ietf.org; Wed, 13 Sep 2006 09:51:17 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNV92-0004mX-NC for ltru@ietf.org; Wed, 13 Sep 2006 09:51:17 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060913135112.BXTN27224.mta10.adelphia.net@DGBP7M81> for ; Wed, 13 Sep 2006 09:51:12 -0400 Message-ID: <004a01c6d73b$aaa7e510$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Wed, 13 Sep 2006 06:51:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] Two subtags with same description (was: Re: 3066ter encompassed languages) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I wrote: >> I don't particularly care for having the same description show up in >> two different entries for things that have different meanings. > > +1. Actually, this makes the confusion even worse if we have to keep > the 639-2 name, because now there will be TWO subtags called simply > "Malay" without qualification. I've been reminded hat we have lots of examples of this already. We have pairs of language and script subtags called Arabic and Gujarati and Mongolian and Thai, pairs of language and region subtags called Tokelau and Tuvalu, etc. I think when the two subtags in question are a primary language subtag and an extended language subtag, there is a much greater potential for users to use the wrong one, and/or to come away with the impression that LTRU made an elementary mistake by assigning two subtags to "the same language." -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 10:17:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNVYY-00061v-C9; Wed, 13 Sep 2006 10:17:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNVYX-00061q-09 for ltru@ietf.org; Wed, 13 Sep 2006 10:17:37 -0400 Received: from smtp1.wsfo.org ([208.145.81.52] helo=smtp2.wsfo.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNVYV-0003NL-MM for ltru@ietf.org; Wed, 13 Sep 2006 10:17:36 -0400 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp2.wsfo.org (8.13.1/8.13.1) with ESMTP id k8DEHZwD027530 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 13 Sep 2006 10:17:35 -0400 X-Scanned-By: MIMEDefang 2.54 on 172.22.0.52 X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp X-Scanned-By: This message was scanned by MPP Free Edition (www.messagepartners.com)! Received: from [203.150.135.56] (account martin_hosken@sil.org HELO [192.168.1.6]) by mail.link77.net (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 122551470 for ltru@ietf.org; Wed, 13 Sep 2006 10:17:34 -0400 Message-ID: <450812FA.3040906@sil.org> Date: Wed, 13 Sep 2006 21:17:30 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: LTRU Working Group X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ltru] script tag for IPA X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear All, A newbie question. What should the tag for English in IPA be? I realise that there are probably two choices for this: a new script IPA or a subscript of Latn. My only thought is that any language may be written using IPA so if a subscript tag must be registered for each language, that's a lot of registration. Apart from that I'm easy either way, I would just like to know what to use. TIA, Martin Hosken _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 10:37:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNVrf-0006PG-TD; Wed, 13 Sep 2006 10:37:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNVre-0006P0-5n for ltru@ietf.org; Wed, 13 Sep 2006 10:37:22 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNVrc-00064D-Nw for ltru@ietf.org; Wed, 13 Sep 2006 10:37:22 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id DB0511E1395; Wed, 13 Sep 2006 07:37:17 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Wed, 13 Sep 2006 07:37:17 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EEF3@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Doug Ewell' , LTRU Working Group Subject: RE: [Ltru] Re: Format of the registry (Was: RFC 4645 on Initial L anguage Subtag Registry Date: Wed, 13 Sep 2006 07:37:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, I think the main reason Record Jar (modified) was chosen over XML for the registry format was because XML source is a pretty terrible format for non-experts to review in an I-D. The other reason may have been misunderstanding of best practices in XML (e.g., using attributes which can't be multivalued versus using elements can be multivalued). Is IANA moving towards XML for IANA registries? I've seen comments to this effect on several IETF WG mailing lists. XML lets us use things much more powerful than XML Schema (like Relax NG and Schematron) to enforce consistency. Record Jar is not going to replace XML as the language du jour for database-like applications. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: Tuesday, September 12, 2006 10:04 AM > To: LTRU Working Group > Subject: [Ltru] Re: Format of the registry (Was: RFC 4645 on Initial > Language Subtag Registry > > > Stephane Bortzmeyer wrote: > > > Before writing my parser, I preferred an XML format. Now > that I have > > written a parser to the registry, I hesitate to continue to > support a > > change which would destroy my work :-) > > I'd have to change my program that converts the Registry into a DLL. > That would be a fair amount of work, and I'm not looking > forward to it, > but we want whatever is best for the Registry and language tagging. > > >> Any news about the supposed plan to move all IANA > registries to XML? > > > > No idea. Do you mind if I ping the IANA about that? > > That would be an excellent idea. Thanks in advance. > > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > RFC 4645 * UTN #14 > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.3/446 - Release Date: 9/12/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 10:38:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNVsx-0006he-H0; Wed, 13 Sep 2006 10:38:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNVsw-0006hZ-3i for ltru@ietf.org; Wed, 13 Sep 2006 10:38:42 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNVsu-0006ZA-PJ for ltru@ietf.org; Wed, 13 Sep 2006 10:38:42 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GNVsu-0005cY-2c; Wed, 13 Sep 2006 10:38:40 -0400 Date: Wed, 13 Sep 2006 10:38:40 -0400 To: Martin Hosken Subject: Re: [Ltru] script tag for IPA Message-ID: <20060913143839.GK10145@ccil.org> References: <450812FA.3040906@sil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450812FA.3040906@sil.org> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Hosken scripsit: > I realise that there are probably two choices for this: a new script IPA > or a subscript of Latn. My only thought is that any language may be > written using IPA so if a subscript tag must be registered for each > language, that's a lot of registration. Apart from that I'm easy either > way, I would just like to know what to use. This is part of the general problem of transliteration/transcription, which is not (yet) handled by the RFC 4646 framework. The best permanent answer is probably to create a -t-xxxx standardized extension to 4646, as provided for, and to create a registration authority to register and maintain codes for different transliterations. No one has hitherto stepped forward to become the registration authority, however. Until then, the best solution is probably to keep the transliteration separate from the RFC 4646 language tag, or else to use -x-something as a private-use transliteration subtag. -- While staying with the Asonu, I met a man from John Cowan the Candensian plane, which is very much like cowan@ccil.org ours, only more of it consists of Toronto. http://:www.ccil.org/~cowan --Ursula K. Le Guin, Changing Planes _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 10:57:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNWAi-0000Qs-AF; Wed, 13 Sep 2006 10:57:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNWAh-0000Qi-D4 for ltru@ietf.org; Wed, 13 Sep 2006 10:57:03 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNWAf-00011h-1y for ltru@ietf.org; Wed, 13 Sep 2006 10:57:03 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 92AA01E1456; Wed, 13 Sep 2006 07:57:00 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Wed, 13 Sep 2006 07:57:00 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EEF4@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Doug Ewell' , LTRU Working Group Subject: RE: [Ltru] Re: Can't add a Preferred-Value to a redundant tag Date: Wed, 13 Sep 2006 07:56:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Deprecated and Preferred-Value fields certainly should carry more weight than Comments fields. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: Wednesday, September 13, 2006 9:20 AM > To: LTRU Working Group > Subject: [Ltru] Re: Can't add a Preferred-Value to a redundant tag > > > John Cowan wrote: > > >> Tag: sgn-US > >> Description: Sign Language as used in the USA > >> Comments: originally registered for ASL. "sgn-ase" is > >> recommended for that meaning. > > > > That's as much as to say the original meaning is > deprecated. So let's > > say so openly, and supply the new tag for that meaning using the > > mechanism designed for that, namely Preferred-Value. > > To clarify: I greatly prefer this solution, whereby if we want to > recommend one tagging solution over another, we use the > Deprecated and > Preferred-Value fields invented for that purpose. But if this is > unacceptable to Addison and others for some reason, I can > live with the > Comments approach. > > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > RFC 4645 * UTN #14 > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.3/446 - Release Date: 9/12/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 11:02:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNWGE-0002ph-N6; Wed, 13 Sep 2006 11:02:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNWGD-0002pc-En for ltru@lists.ietf.org; Wed, 13 Sep 2006 11:02:45 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNWG8-0001hc-50 for ltru@lists.ietf.org; Wed, 13 Sep 2006 11:02:45 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GNWFh-0001NW-VK for ltru@lists.ietf.org; Wed, 13 Sep 2006 17:02:16 +0200 Received: from du-001-165.access.de.clara.net ([212.82.227.165]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Sep 2006 17:02:13 +0200 Received: from nobody by du-001-165.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Sep 2006 17:02:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 13 Sep 2006 16:55:19 +0200 Organization: Lines: 28 Message-ID: <45081BD7.2062@xyzzy.claranet.de> References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> <4506D714.4020705@yahoo-inc.com> <20060913042427.GE10145@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-165.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Ltru] Re: Can't add a Preferred-Value to a redundant tag X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: [3066 sgn-US] > Due to grandfathering, this is still true under RFC 4646. Okay, we got it as syntactically "redundant", but in fact it's semantically "grandfathered". We should say so in a new "sgn" paragraph of the section explaining "redundant" vs. "grandfathered". > That's as much as to say the original meaning is deprecated. > So let's say so openly, and supply the new tag for that > meaning using the mechanism designed for that, namely > Preferred-Value. +1. Some options: 1: Reclassify sgn-XX as exceptionally "grandfathered". 2: Modify the "MUST NOT add Preferred-Value" rule for this special case wannabe-redundant sgn-XX. 3: Modify the "MUST NOT add Preferred-Value" rule for any deprecation triggered by the source standards. I'd like option 3 and a note about sgn-XX in the "redundant" vs. "grandfathered" section. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 11:21:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNWY4-0001gG-Bi; Wed, 13 Sep 2006 11:21:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNWY2-0001gA-QE for ltru@lists.ietf.org; Wed, 13 Sep 2006 11:21:10 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNWY1-0004oZ-H7 for ltru@lists.ietf.org; Wed, 13 Sep 2006 11:21:10 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GNWXY-0005nc-Bd for ltru@lists.ietf.org; Wed, 13 Sep 2006 17:20:40 +0200 Received: from du-001-165.access.de.clara.net ([212.82.227.165]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Sep 2006 17:20:40 +0200 Received: from nobody by du-001-165.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Sep 2006 17:20:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 13 Sep 2006 17:19:06 +0200 Organization: Lines: 26 Message-ID: <4508216A.2745@xyzzy.claranet.de> References: <008401c6d6f2$5930adf0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-165.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Ltru] Re: 3066ter encompassed languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > You may need to remind me of the URL where the document can > be found. If it's "internal" the I* could appoint you as LTRU-liaison to "whatever it takes to get read access". Pointless if that puts you under non-disclosure rules. > this makes the confusion even worse if we have to keep > the 639-2 name, because now there will be TWO subtags called > simply "Malay" without qualification. If one is type extlang and the other type language it's not too bad - we have some identical descriptions with different types. For the "find a simple rule" project: If an old description matches the begin of a new description, only the (longer) new description is registered. Needs some tuning, it's not necessarily a question of "old" vs. "new". Let's keep the inversions, please. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 11:37:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNWoD-0001uJ-5S; Wed, 13 Sep 2006 11:37:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNWoB-0001to-PV for ltru@ietf.org; Wed, 13 Sep 2006 11:37:51 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNWoA-0006bY-81 for ltru@ietf.org; Wed, 13 Sep 2006 11:37:51 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GNWo9-0007XY-MQ for ltru@ietf.org; Wed, 13 Sep 2006 11:37:49 -0400 Date: Wed, 13 Sep 2006 11:37:49 -0400 To: ltru@ietf.org Message-ID: <20060913153749.GL10145@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Ltru] 4646bis-00 review by John Cowan X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This is a preliminary run-through. In 2.2, it would be better to use a valid tag rather than "fr-Latn-CA"; 'fr' has a Suppress-Script of Latn. In the last paragraph, let's use "i-default" rather than "i-enochian", as the latter may eventually become deprecated. 2.2.1 item 2: for "maintenance agengies [sic]" read "registration authorities". The ISO 639 parts and ISO 15924 have registration authorities, because those groups decide what does and does not go in the standard. ISO 3166 has a maintenance agency, because it chooses the subtags but doesn't decide what goes on the list and what doesn't. There are other instances of this problem going back to RFC 1766. 2.2.1: For "It is not expected that future assignments of this nature will occur" read "It is expected that future assignments of this nature will not occur." I think we can safely assume that now. At the end of 2.2.1 there are two consecutive "For example" grafs, the first of which is semantically subordinate to the graf beginning "Note: To avoid problems with [...]" but the second is parallel to it. Change the second "For example" to "Note:" also. 2.2.2 is severely broken, not surprisingly. I'll address this separately. 2.2.4: change the first appearance of "region" to "multi-country region" for clarity, and add a sentence to the first graf something like "Language varieties specific to regions within countries and territories are represented by variant subtags." 2.2.4 item 5: for "as when" read "as when it is not known or" 2.2.9, final bullet point: for "at least one" read "the"; an extlang subtag MUST have exactly one prefix. 3.1 is excessively long and should be separated into pieces. 3.1: for "MAY appear more than one time" read "MAY appear more than once". 3.3: missing spaces before references, leading to "inSection 3.6" and "of[RFC 4646]" in the HTML version. This problem may be more widespread. 3.4, item 17: The exception is misstated: it's not enough that all the subtags in a grandfathered tag are valid, they also have to be in well-formed order. Change to "should a grandfathered tag become equal to a valid tag composed of subtags in the IANA registry" or similar. We can't leave out "composed of subtags" because a grandfathered tag is a valid tag by definition. 3.5 last graf: "Description" is ambiguous; it might be taken as referring to the Description: field in the registration form. Change to "Reference to published description of the language". 3.6 first bullet: for "maintenance or registration" read "registration"; see above. Same story for "maintenance agency" and "agency" in the text just before the addresses for 639 (should this now be 639-1? I don't know), 639-2, and 639-3. 3166 and 15924 are correct. 4.1 item 2: for "which script subtags do not add" read "script subtags that do not add". -- A mosquito cried out in his pain, John Cowan "A chemist has poisoned my brain!" http://www.ccil.org/~cowan The cause of his sorrow cowan@ccil.org Was para-dichloro- Diphenyltrichloroethane. (aka DDT) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 11:55:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNX4t-0000VZ-Sj; Wed, 13 Sep 2006 11:55:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNX4r-0000U8-VJ for ltru@ietf.org; Wed, 13 Sep 2006 11:55:05 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNWrm-0007rv-FG for ltru@ietf.org; Wed, 13 Sep 2006 11:41:36 -0400 Received: from [10.72.72.195] (snvvpn1-10-72-72-c195.corp.yahoo.com [10.72.72.195]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8DFfKbY075118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Sep 2006 08:41:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=1QFVJZbeP6WuLxXcq9z0D0OATrSZXiIOxZUVPUkMRGQqOIixkCvWKmpWRBspve7O Message-ID: <450826A0.2000206@yahoo-inc.com> Date: Wed, 13 Sep 2006 08:41:20 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Can't add a Preferred-Value to a redundant tag References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> <4506D714.4020705@yahoo-inc.com> <004301c6d6e1$72276d50$6401a8c0@DGBP7M81> In-Reply-To: <004301c6d6e1$72276d50$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > >>> I don't know why we allowed grandfathered tags to be assigned a >>> Preferred-Value at a later date, but did not allow the same for >>> redundant tags. >> >> Because redundant tags are, well, redundant. That is, "sgn-BE" will >> still be both "well-formed" and "valid" regardless of what we do with >> extlangs. In fact, it expresses an entirely different value than >> "sgn-bvs" does. One is "Belgian Sign Language", a specific language. >> The other is "sign language(s) as used in Belgium". > > That was my objection all along to this scheme. John points out that these tags have meanings defined by the 3066 registration process, which is true. I don't have a problem with deprecating the tags and it is probably best to include said deprecation in the registry so that users will migrate to the new tags. However... it *does* mean that we'll be breaking our own precedent and (potentially) breaking someone's tags. > >>> ... This would mean two tagging possibilities for the same >>> Description, one of which would be deprecated but would not point to >>> the other. >> >> We will have to decide about this particular point. > > I'd really prefer not to have any more deprecated-at-birth subtags than > absolutely necessary. +1 -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 11:58:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNX8d-0002Ra-MF; Wed, 13 Sep 2006 11:58:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNX8c-0002RR-Ev for ltru@lists.ietf.org; Wed, 13 Sep 2006 11:58:58 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNX8Z-000157-CQ for ltru@lists.ietf.org; Wed, 13 Sep 2006 11:58:58 -0400 Received: from [10.72.72.195] (snvvpn1-10-72-72-c195.corp.yahoo.com [10.72.72.195]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8DFwlYg075799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Sep 2006 08:58:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=PYVoaSQKeyY9Imh3po5WnOVwZRi6Fb1nWCfaJtL5a+7mP0kEfZsMTQNo+yjnVKJV Message-ID: <45082AB7.5040007@yahoo-inc.com> Date: Wed, 13 Sep 2006 08:58:47 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: Can't add a Preferred-Value to a redundant tag References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> <4506D714.4020705@yahoo-inc.com> <20060913042427.GE10145@ccil.org> <45081BD7.2062@xyzzy.claranet.de> In-Reply-To: <45081BD7.2062@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > >> That's as much as to say the original meaning is deprecated. >> So let's say so openly, and supply the new tag for that >> meaning using the mechanism designed for that, namely >> Preferred-Value. > > +1. +1 > Some options: > > 1: Reclassify sgn-XX as exceptionally "grandfathered". > 2: Modify the "MUST NOT add Preferred-Value" rule for this > special case wannabe-redundant sgn-XX. > 3: Modify the "MUST NOT add Preferred-Value" rule for any > deprecation triggered by the source standards. > > I'd like option 3 and a note about sgn-XX in the "redundant" > vs. "grandfathered" section. > I don't like (1). I'd prefer (3). -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 12:01:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNXAm-0003OZ-O9; Wed, 13 Sep 2006 12:01:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNXAl-0003Nz-Du for ltru@ietf.org; Wed, 13 Sep 2006 12:01:11 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNXAk-0001Cn-22 for ltru@ietf.org; Wed, 13 Sep 2006 12:01:11 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1922641nfc for ; Wed, 13 Sep 2006 09:01:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=R/KXlVSiIUE9A5wfQCMukiJqHP6zgo7E/9vjtjfWjLCMXfdaqB2m1tZddDs6amNm/4RjBfyTY43zKeToO0hdkCokTf2RFKycCLbPPCzlvu25/pTPGUBkuPL2bAXVhoZIJc1f1X1J8V3s92v0yfZcI7VOXxy1oAOH9OO+hdPCEpk= Received: by 10.48.48.15 with SMTP id v15mr919906nfv; Wed, 13 Sep 2006 09:01:08 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Wed, 13 Sep 2006 09:01:08 -0700 (PDT) Message-ID: <30b660a20609130901q18d1e97eu2370953c30d34062@mail.gmail.com> Date: Wed, 13 Sep 2006 10:01:08 -0600 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Can't add a Preferred-Value to a redundant tag In-Reply-To: <450826A0.2000206@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> <4506D714.4020705@yahoo-inc.com> <004301c6d6e1$72276d50$6401a8c0@DGBP7M81> <450826A0.2000206@yahoo-inc.com> X-Google-Sender-Auth: 4dcc25eacaedd53c X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org We already put a mechanism in place for this -- semantic widening. sgn-US should simply mean "sign language as used in the US", which is a widening of ASL. To perform that action, actually just dropping from the registry would work. Every tag that was well-formed and valid beforehand is also afterwards; and the semantic is broadened. I'd have to read the rules again to see if that is permitted, however. Mark On 9/13/06, Addison Phillips wrote: > Doug Ewell wrote: > > > >>> I don't know why we allowed grandfathered tags to be assigned a > >>> Preferred-Value at a later date, but did not allow the same for > >>> redundant tags. > >> > >> Because redundant tags are, well, redundant. That is, "sgn-BE" will > >> still be both "well-formed" and "valid" regardless of what we do with > >> extlangs. In fact, it expresses an entirely different value than > >> "sgn-bvs" does. One is "Belgian Sign Language", a specific language. > >> The other is "sign language(s) as used in Belgium". > > > > That was my objection all along to this scheme. > > John points out that these tags have meanings defined by the 3066 > registration process, which is true. I don't have a problem with > deprecating the tags and it is probably best to include said deprecation > in the registry so that users will migrate to the new tags. However... > it *does* mean that we'll be breaking our own precedent and > (potentially) breaking someone's tags. > > > > >>> ... This would mean two tagging possibilities for the same > >>> Description, one of which would be deprecated but would not point to > >>> the other. > >> > >> We will have to decide about this particular point. > > > > I'd really prefer not to have any more deprecated-at-birth subtags than > > absolutely necessary. > > +1 > > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 12:12:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNXLU-0000EQ-2P; Wed, 13 Sep 2006 12:12:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNXLT-0000EL-60 for ltru@ietf.org; Wed, 13 Sep 2006 12:12:15 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNXLR-0002d3-Va for ltru@ietf.org; Wed, 13 Sep 2006 12:12:15 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GNXLR-0000No-Hn; Wed, 13 Sep 2006 12:12:13 -0400 Date: Wed, 13 Sep 2006 12:12:13 -0400 To: Mark Davis Subject: Re: [Ltru] Can't add a Preferred-Value to a redundant tag Message-ID: <20060913161213.GM10145@ccil.org> References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> <4506D714.4020705@yahoo-inc.com> <004301c6d6e1$72276d50$6401a8c0@DGBP7M81> <450826A0.2000206@yahoo-inc.com> <30b660a20609130901q18d1e97eu2370953c30d34062@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20609130901q18d1e97eu2370953c30d34062@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > sgn-US should simply mean "sign language as used in the US", which is > a widening of ASL. Well, but does it then exclude documents (videos, e.g.) that are Canadian in origin? > To perform that action, actually just dropping from > the registry would work. If we were going to drop redundant tags from the registry, we would have avoided putting them in there in the first place. The point about "sgn-US" is that it's syntactically redundant but semantically grandfathered. It is not our business to change its meaning, only to mark it deprecated. -- If you have ever wondered if you are in hell, John Cowan it has been said, then you are on a well-traveled http://www.ccil.org/~cowan road of spiritual inquiry. If you are absolutely cowan@ccil.org sure you are in hell, however, then you must be on the Cross Bronx Expressway. --Alan Feuer, NYTimes, 2002-09-20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 12:14:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNXNX-0001NA-KC; Wed, 13 Sep 2006 12:14:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNXNW-0001N5-AT for ltru@ietf.org; Wed, 13 Sep 2006 12:14:22 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNXNU-0002zq-Tf for ltru@ietf.org; Wed, 13 Sep 2006 12:14:22 -0400 Received: from [10.72.72.195] (snvvpn1-10-72-72-c195.corp.yahoo.com [10.72.72.195]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8DGE85A081342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Sep 2006 09:14:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=mkrNxbRQaK0lsMJ4bM5bfcKjqm2nNtQX92Z0NtnUC0VftkXciaSYxEo56kfAJRXz Message-ID: <45082E4F.40602@yahoo-inc.com> Date: Wed, 13 Sep 2006 09:14:07 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Can't add a Preferred-Value to a redundant tag References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> <4506D714.4020705@yahoo-inc.com> <004301c6d6e1$72276d50$6401a8c0@DGBP7M81> <450826A0.2000206@yahoo-inc.com> <30b660a20609130901q18d1e97eu2370953c30d34062@mail.gmail.com> In-Reply-To: <30b660a20609130901q18d1e97eu2370953c30d34062@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dropping redundant registrations is not permitted. Making them truly redundant, however, is permitted. I'd support both widening the redundant registration and providing a preferred-value (true deprecation). Addison Mark Davis wrote: > We already put a mechanism in place for this -- semantic widening. > > sgn-US should simply mean "sign language as used in the US", which is > a widening of ASL. To perform that action, actually just dropping from > the registry would work. Every tag that was well-formed and valid > beforehand is also afterwards; and the semantic is broadened. I'd have > to read the rules again to see if that is permitted, however. > > Mark > > On 9/13/06, Addison Phillips wrote: >> Doug Ewell wrote: >> > >> >>> I don't know why we allowed grandfathered tags to be assigned a >> >>> Preferred-Value at a later date, but did not allow the same for >> >>> redundant tags. >> >> >> >> Because redundant tags are, well, redundant. That is, "sgn-BE" will >> >> still be both "well-formed" and "valid" regardless of what we do with >> >> extlangs. In fact, it expresses an entirely different value than >> >> "sgn-bvs" does. One is "Belgian Sign Language", a specific language. >> >> The other is "sign language(s) as used in Belgium". >> > >> > That was my objection all along to this scheme. >> >> John points out that these tags have meanings defined by the 3066 >> registration process, which is true. I don't have a problem with >> deprecating the tags and it is probably best to include said deprecation >> in the registry so that users will migrate to the new tags. However... >> it *does* mean that we'll be breaking our own precedent and >> (potentially) breaking someone's tags. >> >> > >> >>> ... This would mean two tagging possibilities for the same >> >>> Description, one of which would be deprecated but would not point to >> >>> the other. >> >> >> >> We will have to decide about this particular point. >> > >> > I'd really prefer not to have any more deprecated-at-birth subtags than >> > absolutely necessary. >> >> +1 >> >> >> -- >> Addison Phillips >> Globalization Architect -- Yahoo! Inc. >> >> Internationalization is an architecture. >> It is not a feature. >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru >> -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 12:49:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNXvn-0007lu-Rj; Wed, 13 Sep 2006 12:49:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNXvn-0007lp-5i for ltru@lists.ietf.org; Wed, 13 Sep 2006 12:49:47 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNXvl-00070w-SS for ltru@lists.ietf.org; Wed, 13 Sep 2006 12:49:47 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GNXvR-0001iQ-Ea for ltru@lists.ietf.org; Wed, 13 Sep 2006 18:49:25 +0200 Received: from du-001-165.access.de.clara.net ([212.82.227.165]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Sep 2006 18:49:25 +0200 Received: from nobody by du-001-165.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Sep 2006 18:49:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 13 Sep 2006 18:48:19 +0200 Organization: Lines: 33 Message-ID: <45083653.20DF@xyzzy.claranet.de> References: <20060913153749.GL10145@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-165.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [Ltru] Re: 4646bis-00 review by John Cowan X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: Going through your list (skipped => ACK): > 2.2.4: change the first appearance of "region" to > "multi-country region" for clarity Soryy, I don't get this. The first sentence starting with "Region subtags are used" [...] is okay, > add a sentence to the first graf something like "Language > varieties specific to regions within countries and > territories are represented by variant subtags." More like "could be represented" (if registered), or "can be represented by registered variant subtags" (with a pointer to the next section about variants). A statement about this could also be added as new point 7 of the 2.2.4 list (instead of adding it to the 2.2.4 intro). > 3.1 is excessively long and should be separated into pieces. Indeed, the stuff about Deprecated and Preferred-Value could be one of those 3.1.x pieces, or a single new subsection 3.1.1. [3.4.17] > Change to "should a grandfathered tag become equal to a valid > tag composed of subtags in the IANA registry" or similar. Maybe ..."valid tag composed of registered subtags" (shorter). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 12:50:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNXw6-0007nN-H8; Wed, 13 Sep 2006 12:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNXw5-0007nI-5J for ltru@ietf.org; Wed, 13 Sep 2006 12:50:05 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNXw3-00073i-Jf for ltru@ietf.org; Wed, 13 Sep 2006 12:50:05 -0400 Received: from [10.72.72.195] (snvvpn1-10-72-72-c195.corp.yahoo.com [10.72.72.195]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8DGnqM3077988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Sep 2006 09:49:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=totdbU5EuF9AU/RBnWNxv185KzPMAHkSvMp8xGPaVeuwauaIB6qm7rhbQD1EvhA2 Message-ID: <450836B0.4010008@yahoo-inc.com> Date: Wed, 13 Sep 2006 09:49:52 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] 4646bis-00 review by John Cowan References: <20060913153749.GL10145@ccil.org> In-Reply-To: <20060913153749.GL10145@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Comments follow. Editor's copy updated and posted to inter-locale. A wdiff link is included there. I note that TinyURL has decided that tools.ietf.org is a "frequently spammed" site. I'm going to have to switch to del.icio.us or Y!Scuttle for my short URLs.... Addison John Cowan wrote: > This is a preliminary run-through. > > In 2.2, it would be better to use a valid tag rather than "fr-Latn-CA"; > 'fr' has a Suppress-Script of Latn. Changed to use 'Hant' and "zh-Hant-CN". This, of course, is an example from 4646... > > In the last paragraph, let's use "i-default" rather than "i-enochian", > as the latter may eventually become deprecated. Done. > > 2.2.1 item 2: for "maintenance agengies [sic]" read "registration > authorities". The ISO 639 parts and ISO 15924 have registration > authorities, because those groups decide what does and does not go in > the standard. ISO 3166 has a maintenance agency, because it chooses > the subtags but doesn't decide what goes on the list and what doesn't. > There are other instances of this problem going back to RFC 1766. Typo fixed. Terminology fixed in 2.2.1, 2.2.2, etc. > > 2.2.1: For "It is not expected that future assignments of this nature > will occur" read "It is expected that future assignments of this nature > will not occur." I think we can safely assume that now. Changed the syntax. > > At the end of 2.2.1 there are two consecutive "For example" grafs, > the first of which is semantically subordinate to the graf beginning > "Note: To avoid problems with [...]" but the second is parallel to it. > Change the second "For example" to "Note:" also. Changed to: Note: An example of independent primary language subtag registration might include: 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. Making the item a note required some additional text explaining what it was. It might be better just to lose the example altogether. > > 2.2.2 is severely broken, not surprisingly. I'll address this separately. It is severely "not there yet" :-). > > 2.2.4: change the first appearance of "region" to "multi-country > region" for clarity, No. That doesn't make sense: the first appearance is defining what "region subtag" is. Please suggest the specific text, if you think this in error. > and add a sentence to the first graf something like > "Language varieties specific to regions within countries and territories > are represented by variant subtags." I don't think this text would be appropriate on two points: 1. It would be better to say "could be represented by variant subtags", since no sub-regional subtags are registered. 2. The rules make this happen anyway. > > 2.2.4 item 5: for "as when" read "as when it is not known or" I don't think this adds anything necessary to the document. > > 2.2.9, final bullet point: for "at least one" read "the"; an extlang > subtag MUST have exactly one prefix. This item is a mess, actually. I changed it to: For extended language subtags, check that the tag matches the 'Prefix' field associated with the subtag. The tag matches if the 'Prefix' exactly matches the start of the tag. For example, the prefix "sgn-ase" matches the tag "sgn-ase-US" but does not match the tag "sgn-bvs-ase-US". > > 3.1 is excessively long and should be separated into pieces. I'll consider how to break it up, but would prefer not to. I don't see the need to introduce changes to 4646 text if we don't have to. The time to edit 4646 was in draft-registry. > > 3.1: for "MAY appear more than one time" read "MAY appear more than once". Done. > > 3.3: missing spaces before references, leading to "inSection 3.6" and > "of[RFC 4646]" in the HTML version. This problem may be more widespread. Spaces are present in the XML. Will investigate further. > > 3.4, item 17: The exception is misstated: it's not enough that all > the subtags in a grandfathered tag are valid, they also have to be in > well-formed order. Change to "should a grandfathered tag become equal > to a valid tag composed of subtags in the IANA registry" or similar. > We can't leave out "composed of subtags" because a grandfathered tag > is a valid tag by definition. Good point. I changed it thusly: -- Stability provisions apply to grandfathered tags with this exception: should it be possible to compose one of the grandfathered tags from registered subtags, then the field 'Type' in that record is changed from 'grandfathered' to 'redundant'. -- I note that this bears on our discussion of allowing Preferred-Value/Deprecated into redundant tags: if a grandfathered tag has picked up this baggage, wouldn't it stand to reason that the redundant tag would keep it? > > 3.5 last graf: "Description" is ambiguous; it might be taken as referring > to the Description: field in the registration form. Change to "Reference > to published description of the language". Already done per Frank's comments. > > 3.6 first bullet: for "maintenance or registration" read "registration"; > see above. Same story for "maintenance agency" and "agency" in the text > just before the addresses for 639 (should this now be 639-1? I don't > know), 639-2, and 639-3. 3166 and 15924 are correct. Done. > > 4.1 item 2: for "which script subtags do not add" read "script subtags > that do not add". > Done. -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 13:10:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYFb-0008Q9-FI; Wed, 13 Sep 2006 13:10:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYFa-0008Q3-55 for ltru@lists.ietf.org; Wed, 13 Sep 2006 13:10:14 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNYFY-0000Qc-DA for ltru@lists.ietf.org; Wed, 13 Sep 2006 13:10:14 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GNYFJ-0006cK-Cp for ltru@lists.ietf.org; Wed, 13 Sep 2006 19:09:57 +0200 Received: from du-001-165.access.de.clara.net ([212.82.227.165]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Sep 2006 19:09:57 +0200 Received: from nobody by du-001-165.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Sep 2006 19:09:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 13 Sep 2006 19:09:06 +0200 Organization: Lines: 26 Message-ID: <45083B32.43C8@xyzzy.claranet.de> References: <789E617C880666438EDEE30C2A3E8D10EEF3@mailsrvnt05.enet.sharplabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-165.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Ltru] Re: Format of the registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org McDonald, Ira wrote: > XML source is a pretty terrible format for non-experts to > review in an I-D. Depends, is almost obvious, for the native ICU format you'd need the rules (ABNF). > XML lets us use things much more powerful than XML Schema > (like Relax NG and Schematron) to enforce consistency. ABNF is also nice, one advantage is that I know it. Willing to sign a "4234 to STD" petition (including any "fight it out with Bruce" obligation). > Record Jar is not going to replace XML as the language du > jour for database-like applications. The SPF folks use something that's called YAML for their test suite (picked out of XML, JSON, YAML). It really depends on what you need. I read Stephane's Cosmogol draft, this can't _directly_ replace the state machine in CharMapML with its 256 "messages" (= octets) in any state. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 13:16:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYLY-0002S8-8R; Wed, 13 Sep 2006 13:16:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYLX-0002S3-8z for ltru@ietf.org; Wed, 13 Sep 2006 13:16:23 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNYLT-0001my-TW for ltru@ietf.org; Wed, 13 Sep 2006 13:16:23 -0400 Received: from [10.72.72.195] (snvvpn1-10-72-72-c195.corp.yahoo.com [10.72.72.195]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8DHGDOc084002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Sep 2006 10:16:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=WIG2F+VsOH+mWluvmpjCdST4qzJu1KeWYXfcLIHAer2tUr9AX8l+rWN92IoV4ks4 Message-ID: <45083CDD.2050908@yahoo-inc.com> Date: Wed, 13 Sep 2006 10:16:13 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "'LTRU Working Group'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ltru] further edits... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org 3.4, point 17 includes this example: -- For example, if the subtag 'gan' in the language tag "zh-gan" were to be registered as an extended language subtag, then the grandfathered tag "zh-gan" would be deprecated (but existing content or implementations that use "zh-gan" would remain valid). -- In light of this document (and the fact that we're showing the move from grandfathered to redundant in the example), I have changed this text to read: -- 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). -- Addison Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 13:22:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYRo-00049p-LR; Wed, 13 Sep 2006 13:22:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYRn-00049G-2q for ltru@ietf.org; Wed, 13 Sep 2006 13:22:51 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNYRl-0003TF-RX for ltru@ietf.org; Wed, 13 Sep 2006 13:22:51 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GNYRl-0002Zi-7F; Wed, 13 Sep 2006 13:22:49 -0400 Date: Wed, 13 Sep 2006 13:22:49 -0400 To: Addison Phillips Subject: Re: [Ltru] 4646bis-00 review by John Cowan Message-ID: <20060913172247.GO10145@ccil.org> References: <20060913153749.GL10145@ccil.org> <450836B0.4010008@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450836B0.4010008@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > >2.2.4: change the first appearance of "region" to "multi-country > >region" for clarity, > > No. That doesn't make sense: the first appearance is defining what > "region subtag" is. Please suggest the specific text, if you think this > in error. Sorry, I specified this badly. I meant to suggest changing "specific country, territory, or region" to "specific country, territory, or multi-country region." I did not mean to change the term "Region subtag", of course. Come to think of it, "territory" is also bad, though I don't have anything better to suggest. > 1. It would be better to say "could be represented by variant subtags", > since no sub-regional subtags are registered. +1 > 2. The rules make this happen anyway. Sure, but saying so redundantly here adds clarity. > >2.2.4 item 5: for "as when" read "as when it is not known or" > > I don't think this adds anything necessary to the document. I think it's useful to point out that adding subtags you are not sure of just to be adding them is a Bad Thing. If you don't know if the document is en-US or en-UK or ..., stick with en. Perhaps this should be made more explicit. > I'll consider how to break it up, but would prefer not to. I don't see > the need to introduce changes to 4646 text if we don't have to. The time > to edit 4646 was in draft-registry. My review was a de novo one; I should have made that clear from the beginning. > I note that this bears on our discussion of allowing > Preferred-Value/Deprecated into redundant tags: if a grandfathered tag > has picked up this baggage, wouldn't it stand to reason that the > redundant tag would keep it? +1 -- John Cowan cowan@ccil.org http://ccil.org/~cowan Linguistics is arguably the most hotly contested property in the academic realm. It is soaked with the blood of poets, theologians, philosophers, philologists, psychologists, biologists and neurologists, along with whatever blood can be got out of grammarians. - Russ Rymer _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 13:30:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYYz-00083T-UY; Wed, 13 Sep 2006 13:30:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYYy-00082z-Mh for ltru@lists.ietf.org; Wed, 13 Sep 2006 13:30:16 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNYYx-0004Zv-Bm for ltru@lists.ietf.org; Wed, 13 Sep 2006 13:30:16 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GNYYk-0002n6-KV for ltru@lists.ietf.org; Wed, 13 Sep 2006 19:30:02 +0200 Received: from du-001-165.access.de.clara.net ([212.82.227.165]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Sep 2006 19:30:02 +0200 Received: from nobody by du-001-165.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Sep 2006 19:30:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Followup-To: gmane.ietf.tools Date: Wed, 13 Sep 2006 19:27:02 +0200 Organization: Lines: 24 Message-ID: <45083F66.7E6E@xyzzy.claranet.de> References: <20060913153749.GL10145@ccil.org> <450836B0.4010008@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-165.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tools-discuss@ietf.org Subject: [Ltru] Tiny URLs (was: 4646bis-00 review by John Cowan) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote on tge LTRU list: > I note that TinyURL has decided that tools.ietf.org is a > "frequently spammed" site. I'm going to have to switch to > del.icio.us or Y!Scuttle for my short URLs.... Sigh, forwarded to the "tools" list, could we get a default url1= if only url2= is specifified ? The algorithm would be: 1: strip and note any extension like ".txt" at the last dot 2: split version after last hyphen-minus like 03 for "...-03" 3: concatenate the rest plus version -1 (02) plus extension to get a default url1. And maybe let &difftype=--hwdiff be the default, instead of the side-by-side diff (?) It's okay if the tinyurl folks are paranoid, they were or are blacklisted by wikipedia after some abuse. For redirectors SURBL offers a way to fight abuse: Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 13:42:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYkV-0004IC-Dc; Wed, 13 Sep 2006 13:42:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYkT-0004I4-Pl for ltru@ietf.org; Wed, 13 Sep 2006 13:42:09 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNYkS-0006Sb-5k for ltru@ietf.org; Wed, 13 Sep 2006 13:42:09 -0400 Received: from [10.72.72.195] (snvvpn1-10-72-72-c195.corp.yahoo.com [10.72.72.195]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8DHg47d080465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Sep 2006 10:42:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=jHmMOwTmZ3f77rFWSIbj6cznuiH3Kh+2I/iv7fAVmJZzf2WPSNsaOcWsSjvyadSa Message-ID: <450842EC.3030007@yahoo-inc.com> Date: Wed, 13 Sep 2006 10:42:04 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "'LTRU Working Group'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [Ltru] Preferred-Value fun... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I note some problems with Preferred-Value, which I'm cleaning as follows: 1. Currently the definition of P-V says: -- o Preferred-Value * For fields of type 'language', 'extlang', 'script', 'region', and 'variant', 'Preferred-Value' contains the subtag of the same 'Type' that is preferred for forming the language tag. * For fields of type 'grandfathered' and 'redundant', a canonical mapping to a complete language tag. -- Notice that this won't work for 'language' and 'extlang' subtags in all situation. I'm changing to: -- Preferred-Value For fields of type 'script', 'region', and 'variant', 'Preferred-Value' contains the subtag of the same 'Type' that is preferred for forming the language tag. For fields of type 'language' and 'extlang', 'Preferred-Value' contains the language production (see ) that is preferred when forming the language tag. This can be simply a 'language' subtag, or it can be a 'language' subtag followed by an extended language sequence. For fields of type 'grandfathered' and 'redundant', a canonical mapping to a complete language tag. -- 2. Elsewhere in that section it says: -- 3. Tags grandfathered from RFC 3066. -- ... which I changed to: -- 3. Grandfathered or redundant tags from RFC 3066. -- 3. The prohibition of new Preferred-Values paragraph needs attention, per the threads over the past couple of days. Here is the old para: -- The field 'Preferred-Value' MUST NOT be modified once created in the registry. The field MAY be added to records of type "grandfathered" and "region" according to the rules in . Otherwise the field MUST NOT be added to any record already in the registry. -- Here is my proposed new para: -- The field 'Preferred-Value' MUST NOT be modified once created in the registry. The field MAY be added to records according to the rules in . -- -- -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 13:52:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYu9-0008Ho-O2; Wed, 13 Sep 2006 13:52:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYu8-0008Hi-Ix for ltru@lists.ietf.org; Wed, 13 Sep 2006 13:52:08 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNYu7-0007h1-8a for ltru@lists.ietf.org; Wed, 13 Sep 2006 13:52:08 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GNYu1-0007xM-NU for ltru@lists.ietf.org; Wed, 13 Sep 2006 19:52:01 +0200 Received: from du-001-165.access.de.clara.net ([212.82.227.165]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Sep 2006 19:52:01 +0200 Received: from nobody by du-001-165.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Sep 2006 19:52:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 13 Sep 2006 19:51:18 +0200 Organization: Lines: 10 Message-ID: <45084516.15B3@xyzzy.claranet.de> References: <450842EC.3030007@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-165.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] Re: Preferred-Value fun... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > some problems with Preferred-Value, which I'm cleaning Sounds good, and for the identification of redundant sgn-XX tags their registration forms are still available at IANA: Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 13:54:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYvr-0000P2-VS; Wed, 13 Sep 2006 13:53:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYvq-0000Ox-Jo for ltru@ietf.org; Wed, 13 Sep 2006 13:53:54 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNYvp-0007n3-82 for ltru@ietf.org; Wed, 13 Sep 2006 13:53:54 -0400 Received: from [10.72.72.195] (snvvpn1-10-72-72-c195.corp.yahoo.com [10.72.72.195]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8DHrdE0081002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Sep 2006 10:53:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=gDum0gAPr9iVrkrZdlybJA789nwyFYrDYoo5DV4E64eoHthw93vfP3IZC7j2eMlb Message-ID: <450845A3.1010904@yahoo-inc.com> Date: Wed, 13 Sep 2006 10:53:39 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] 4646bis-00 review by John Cowan References: <20060913153749.GL10145@ccil.org> <450836B0.4010008@yahoo-inc.com> <20060913172247.GO10145@ccil.org> In-Reply-To: <20060913172247.GO10145@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > Sorry, I specified this badly. I meant to suggest changing "specific > country, territory, or region" to "specific country, territory, or > multi-country region." I did not mean to change the term "Region > subtag", of course. > > Come to think of it, "territory" is also bad, though I don't have > anything better to suggest. Thanks for the clarification. Hmm.. that text is kind of awkward. I'll play with it in the next edit session. > >> 1. It would be better to say "could be represented by variant subtags", >> since no sub-regional subtags are registered. > > +1 > >> 2. The rules make this happen anyway. > > Sure, but saying so redundantly here adds clarity. Okay. > >>> 2.2.4 item 5: for "as when" read "as when it is not known or" >> I don't think this adds anything necessary to the document. > > I think it's useful to point out that adding subtags you are > not sure of just to be adding them is a Bad Thing. If you > don't know if the document is en-US or en-UK or ..., stick > with en. Perhaps this should be made more explicit. Not a bad idea in general, but not strictly necessary here. I find the resulting sentence more potentially confusing (for an example). > >> I'll consider how to break it up, but would prefer not to. I don't see >> the need to introduce changes to 4646 text if we don't have to. The time >> to edit 4646 was in draft-registry. > > My review was a de novo one; I should have made that clear from the > beginning. I recognize that. I'm okay with a de novo review (it is good to use fresh eyes). My point is that I'm expressing an "editorial preference" not to make wide changes in the structure of the document. I'd prefer not to introduce a lot more change in the text, if possible, too, although the change bars are going lots of places as it is..... Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 14:12:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNZDW-0006sT-9A; Wed, 13 Sep 2006 14:12:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNZDV-0006sF-G0 for ltru@ietf.org; Wed, 13 Sep 2006 14:12:09 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNZDG-0001tQ-IV for ltru@ietf.org; Wed, 13 Sep 2006 14:11:55 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1960609nfc for ; Wed, 13 Sep 2006 11:11:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=H7zYMVZ9ah6wKZtYzoW7i2AFpPbaoC/jeemF7SLTxe+QNHjxltVeewq2a1eyh2FEzDwbrgJ9QbNV85ecpnsQ9GKC97Nhgd/XLCxrYKZpuKQ+8S/hxswY7Kj5hKDE6/lsJ7dG7eqALQUu91yvN721GFxviVMuFKt8SaNY+0oriQ8= Received: by 10.49.29.3 with SMTP id g3mr11177714nfj; Wed, 13 Sep 2006 11:11:52 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Wed, 13 Sep 2006 11:11:52 -0700 (PDT) Message-ID: <30b660a20609131111h33b9eb5fle120c6c0a9686753@mail.gmail.com> Date: Wed, 13 Sep 2006 11:11:52 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] 4646bis-00 review by John Cowan In-Reply-To: <450845A3.1010904@yahoo-inc.com> MIME-Version: 1.0 References: <20060913153749.GL10145@ccil.org> <450836B0.4010008@yahoo-inc.com> <20060913172247.GO10145@ccil.org> <450845A3.1010904@yahoo-inc.com> X-Google-Sender-Auth: 4c300d21171e3fc5 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0291282452==" Errors-To: ltru-bounces@ietf.org --===============0291282452== Content-Type: multipart/alternative; boundary="----=_Part_82833_29528842.1158171112734" ------=_Part_82833_29528842.1158171112734 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline ++1 > My review was a de novo one; I should have made that clear from the > > beginning. > > I recognize that. I'm okay with a de novo review (it is good to use > fresh eyes). My point is that I'm expressing an "editorial preference" > not to make wide changes in the structure of the document. I'd prefer > not to introduce a lot more change in the text, if possible, too, > although the change bars are going lots of places as it is..... > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_82833_29528842.1158171112734 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

++1

> My review was a de novo one; I should have made that clear from the
> beginning.

I recognize that. I'm okay with a de novo review (it is good to use
fresh eyes). My point is that I'm expressing an "editorial preference"
not to make wide changes in the structure of the document. I'd prefer
not to introduce a lot more change in the text, if possible, too,
although the change bars are going lots of places as it is.....

Addison

--
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

------=_Part_82833_29528842.1158171112734-- --===============0291282452== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0291282452==-- From ltru-bounces@ietf.org Wed Sep 13 14:12:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNZEB-0007Iu-OB; Wed, 13 Sep 2006 14:12:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNZEA-0007IV-Gi for ltru@ietf.org; Wed, 13 Sep 2006 14:12:50 -0400 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNZ4A-0000as-Es for ltru@ietf.org; Wed, 13 Sep 2006 14:02:33 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=iRzmC26LpAdfEUoHprk6zUio46SjAe9tEAJFoa7OVxI9Y/Mr2S36YmvTzLEhRHlx; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.2.31] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GNZ47-0002lC-Fd for ltru@ietf.org; Wed, 13 Sep 2006 14:02:27 -0400 Message-ID: <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> From: "Randy Presuhn" To: References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> Subject: Re: [Ltru] script tag for IPA Date: Wed, 13 Sep 2006 11:05:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7af79bf75c18dea22a281fb739c5cf7ce5f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.2.31 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "John Cowan" > To: "Martin Hosken" > Cc: > Sent: Wednesday, September 13, 2006 7:38 AM > Subject: Re: [Ltru] script tag for IPA > > Martin Hosken scripsit: > > > I realise that there are probably two choices for this: a new script IPA > > or a subscript of Latn. My only thought is that any language may be > > written using IPA so if a subscript tag must be registered for each > > language, that's a lot of registration. Apart from that I'm easy either > > way, I would just like to know what to use. > > This is part of the general problem of transliteration/transcription, > which is not (yet) handled by the RFC 4646 framework. The best permanent > answer is probably to create a -t-xxxx standardized extension to > 4646, as provided for, and to create a registration authority to > register and maintain codes for different transliterations. > > No one has hitherto stepped forward to become the registration authority, > however. > > Until then, the best solution is probably to keep the transliteration > separate from the RFC 4646 language tag, or else to use -x-something > as a private-use transliteration subtag. ... As a technical contributor... Although it would be nice to have a general solution to the transcription / transliteration problem, perhaps IPA transcriptions are common and important enough to merit an immediate solution, even while recognizing that a given utterance may be transcribed in a large number of ways, depending on the needs and preferences of the transcriber. What would it take to have the powers that be add a four-letter script code for it? Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 14:17:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNZIO-0001C5-JY; Wed, 13 Sep 2006 14:17:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNZIN-0001By-5k for ltru@ietf.org; Wed, 13 Sep 2006 14:17:11 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNZIL-00032f-UG for ltru@ietf.org; Wed, 13 Sep 2006 14:17:11 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GNZIL-0004KI-Fm; Wed, 13 Sep 2006 14:17:09 -0400 Date: Wed, 13 Sep 2006 14:17:09 -0400 To: Randy Presuhn Subject: Re: [Ltru] script tag for IPA Message-ID: <20060913181709.GQ10145@ccil.org> References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > Although it would be nice to have a general solution to the transcription / > transliteration problem, perhaps IPA transcriptions are common and > important enough to merit an immediate solution, even while recognizing > that a given utterance may be transcribed in a large number of ways, > depending on the needs and preferences of the transcriber. What > would it take to have the powers that be add a four-letter script code > for it? There's only one relevant power that be, and that's (qua ISO 19542 Registrar, not qua LSTR), and he's already rejected it. Good luck. -- How they ever reached any conclusion at all is starkly unknowable to the human mind. http://www.ccil.org/~cowan --"Backstage Lensman", Randall Garrett _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 14:19:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNZKu-0002lY-SK; Wed, 13 Sep 2006 14:19:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNZKu-0002lT-0V for ltru@ietf.org; Wed, 13 Sep 2006 14:19:48 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNZKs-0003WC-E0 for ltru@ietf.org; Wed, 13 Sep 2006 14:19:47 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1962729nfc for ; Wed, 13 Sep 2006 11:19:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=RCufAmnaMvw/bo+PtAve5CHJFtQAI9Trp6TMu+FiMJzHQkCD6vrdHuNW9asCafMKZ8l7gBxmkOA1AThGq4IrYD/SVYS8Iuyoc6prRoDjYxZRB0rUCUGtbfS9zPqTSKKEv5fGwik4hl2hJO8TROMg4xOYf2XhoX+s+OykwIO+syI= Received: by 10.49.43.2 with SMTP id v2mr11197406nfj; Wed, 13 Sep 2006 11:19:45 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Wed, 13 Sep 2006 11:19:44 -0700 (PDT) Message-ID: <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> Date: Wed, 13 Sep 2006 11:19:44 -0700 From: "Mark Davis" To: "Randy Presuhn" Subject: Re: [Ltru] script tag for IPA In-Reply-To: <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> MIME-Version: 1.0 References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> X-Google-Sender-Auth: 758e07ed7e6ac028 X-Spam-Score: 0.5 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Michael Everson , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1584724050==" Errors-To: ltru-bounces@ietf.org --===============1584724050== Content-Type: multipart/alternative; boundary="----=_Part_83061_903047.1158171584948" ------=_Part_83061_903047.1158171584948 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline That was raised on the script JAC. I personally think it's a good idea. The script code already incorporates variations which are essentially orthography (Hant vs Hans), and other differences that are simply glyphic variation (Fraktur Latin). It would be extremely useful if we had an IPA variant script (and for that matter, a polytonic variant script). But I'll include Everson on this so that he can voice his opinion. Mark On 9/13/06, Randy Presuhn wrote: > > Hi - > > > From: "John Cowan" > > To: "Martin Hosken" > > Cc: > > Sent: Wednesday, September 13, 2006 7:38 AM > > Subject: Re: [Ltru] script tag for IPA > > > > > Martin Hosken scripsit: > > > > > I realise that there are probably two choices for this: a new script > IPA > > > or a subscript of Latn. My only thought is that any language may be > > > written using IPA so if a subscript tag must be registered for each > > > language, that's a lot of registration. Apart from that I'm easy > either > > > way, I would just like to know what to use. > > > > This is part of the general problem of transliteration/transcription, > > which is not (yet) handled by the RFC 4646 framework. The best > permanent > > answer is probably to create a -t-xxxx standardized extension to > > 4646, as provided for, and to create a registration authority to > > register and maintain codes for different transliterations. > > > > No one has hitherto stepped forward to become the registration > authority, > > however. > > > > Until then, the best solution is probably to keep the transliteration > > separate from the RFC 4646 language tag, or else to use -x-something > > as a private-use transliteration subtag. > ... > > As a technical contributor... > > Although it would be nice to have a general solution to the transcription > / > transliteration problem, perhaps IPA transcriptions are common and > important enough to merit an immediate solution, even while recognizing > that a given utterance may be transcribed in a large number of ways, > depending on the needs and preferences of the transcriber. What > would it take to have the powers that be add a four-letter script code > for it? > > Randy > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_83061_903047.1158171584948 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline That was raised on the script JAC.

I personally think it's a good idea. The script code already incorporates variations which are essentially orthography (Hant vs Hans), and other differences that are simply glyphic variation (Fraktur Latin). It would be extremely useful if we had an IPA variant script (and for that matter, a polytonic variant script).

But I'll include Everson on this so that he can voice his opinion.

Mark

On 9/13/06, Randy Presuhn < randy_presuhn@mindspring.com> wrote:
Hi -

> From: "John Cowan" < cowan@ccil.org>
> To: "Martin Hosken" <martin_hosken@sil.org>
> Cc: <ltru@ietf.org >
> Sent: Wednesday, September 13, 2006 7:38 AM
> Subject: Re: [Ltru] script tag for IPA
>

> Martin Hosken scripsit:
>
> > I realise that there are probably two choices for this: a new script IPA
> > or a subscript of Latn. My only thought is that any language may be
> > written using IPA so if a subscript tag must be registered for each
> > language, that's a lot of registration. Apart from that I'm easy either
> > way, I would just like to know what to use.
>
> This is part of the general problem of transliteration/transcription,
> which is not (yet) handled by the RFC 4646 framework.  The best permanent
> answer is probably to create a -t-xxxx standardized extension to
> 4646, as provided for, and to create a registration authority to
> register and maintain codes for different transliterations.
>
> No one has hitherto stepped forward to become the registration authority,
> however.
>
> Until then, the best solution is probably to keep the transliteration
> separate from the RFC 4646 language tag, or else to use -x-something
> as a private-use transliteration subtag.
...

As a technical contributor...

Although it would be nice to have a general solution to the transcription /
transliteration problem, perhaps IPA transcriptions are common and
important enough to merit an immediate solution, even while recognizing
that a given utterance may be transcribed in a large number of ways,
depending on the needs and preferences of the transcriber.  What
would it take to have the powers that be add a four-letter script code
for it?

Randy


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

------=_Part_83061_903047.1158171584948-- --===============1584724050== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1584724050==-- From ltru-bounces@ietf.org Wed Sep 13 15:49:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNajv-0005rG-Ew; Wed, 13 Sep 2006 15:49:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNaju-0005rB-5r for ltru@ietf.org; Wed, 13 Sep 2006 15:49:42 -0400 Received: from white.dnsireland.com ([67.15.182.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNajn-0004CQ-SR for ltru@ietf.org; Wed, 13 Sep 2006 15:49:42 -0400 Received: from [88.81.100.235] (port=35926 helo=[10.0.1.3]) by white.dnsireland.com with esmtpa (Exim 4.52) id 1GNajS-0000Ew-Vw; Wed, 13 Sep 2006 20:49:15 +0100 Mime-Version: 1.0 Message-Id: In-Reply-To: <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> Date: Wed, 13 Sep 2006 20:49:03 +0100 To: "Mark Davis" , "Randy Presuhn" From: Michael Everson Subject: Re: [Ltru] script tag for IPA Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - white.dnsireland.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - evertype.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Doug Ewell , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 11:19 -0700 2006-09-13, Mark Davis wrote: >That was raised on the script JAC. > >I personally think it's a good idea. The script=20 >code already incorporates variations which are=20 >essentially orthography (Hant vs Hans), and=20 >other differences that are simply glyphic=20 >variation (Fraktur Latin). It would be extremely=20 >useful if we had an IPA variant script (and for=20 >that matter, a polytonic variant script). > >But I'll include Everson on this so that he can voice his opinion. I have opposed this kind of thing for a long=20 time, because IPA isn't a script. Nor is it a=20 style in the way that Fraktur or Gaelic are=20 styles of Latin. Polytonic Greek orthography is *not* a variant of=20 the Greek script. It is an orthography which=20 simply uses more characters than Monotonic Greek=20 orthography does. There is no justification for=20 suggesting otherwise, as I have said to you=20 before on that issue. Polytonic orthography=20 simply uses more (Greek) characters than=20 Monotonic does. You might as well suggest that ASCII-only English=20 uses a different script from English which uses=20 diacritical marks as in fa=E7ade, co=F6perate,=20 r=E9sum=E9, na=EFve, r=F4le, or belov=E8d. But that=20 wouldn't be correct. One orthography simply uses=20 more (Latin) characters than the other. Similarly, apart from a few straggling imports=20 from Greek (which should be represented by Latin=20 clones for a variety of reasons), all of the IPA=20 characters are Latin. Many natural orthographies,=20 in Africa for instance, use characters which=20 originated as phonetic characters. There is also the problem that other Latin=20 phonetic alphabets exist which are not IPA.=20 Here's a test. Consider the text [paketilonu].=20 What script is it written in? Latin? The=20 "International Phonetic Alphabet"? The "Uralic=20 Phonetic Alphabet"? The "Lepsius Phonetic=20 Alphabet"? Answer: All of the above. Ergo: Latn. -- Michael Everson * http://www.evertype.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 16:29:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNbMm-0005tu-GU; Wed, 13 Sep 2006 16:29:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNbMl-0005te-6h for ltru@ietf.org; Wed, 13 Sep 2006 16:29:51 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNbMj-00024W-VR for ltru@ietf.org; Wed, 13 Sep 2006 16:29:51 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GNbMh-0000aP-PH; Wed, 13 Sep 2006 16:29:47 -0400 Date: Wed, 13 Sep 2006 16:29:47 -0400 To: Michael Everson Subject: Re: [Ltru] script tag for IPA Message-ID: <20060913202947.GC22114@ccil.org> References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Michael Everson scripsit: > You might as well suggest that ASCII-only English > uses a different script from English which uses > diacritical marks as in façade, coöperate, > résumé, naïve, rôle, or belovèd. But that > wouldn't be correct. One orthography simply uses > more (Latin) characters than the other. Sub-scripts are introduced for practical reasons. Hans and Hant are just subsets of Hani, but it's handy to be able to differentiate, and the difference is more like a script difference than it is like anything else. > There is also the problem that other Latin phonetic alphabets exist > which are not IPA. Here's a test. Consider the text [paketilonu]. > What script is it written in? Latin? The "International Phonetic > Alphabet"? The "Uralic Phonetic Alphabet"? The "Lepsius Phonetic > Alphabet"? > > Answer: All of the above. Ergo: Latn. "What language is 'chat' written in? English? French? Answer: both. Ergo: Hmmm." Is Lisu (in the Fraser orthography) written in Latn? It too uses a small subset of Latin letters plus some novel ones. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Humpty Dump Dublin squeaks through his norse Humpty Dump Dublin hath a horrible vorse But for all his kinks English / And his irismanx brogues Humpty Dump Dublin's grandada of all rogues. --Cousin James _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 16:30:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNbNE-00066Q-0G; Wed, 13 Sep 2006 16:30:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNbND-000663-7S for ltru@lists.ietf.org; Wed, 13 Sep 2006 16:30:19 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNbNA-0002Gr-Sn for ltru@lists.ietf.org; Wed, 13 Sep 2006 16:30:19 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GNbMw-0000Cr-Jz for ltru@lists.ietf.org; Wed, 13 Sep 2006 22:30:02 +0200 Received: from pd9fbadc1.dip0.t-ipconnect.de ([217.251.173.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Sep 2006 22:30:02 +0200 Received: from nobody by pd9fbadc1.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Sep 2006 22:30:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 13 Sep 2006 22:25:34 +0200 Organization: Lines: 13 Message-ID: <4508693E.1ECA@xyzzy.claranet.de> References: <20060913153749.GL10145@ccil.org> <450836B0.4010008@yahoo-inc.com> <45083F66.7E6E@xyzzy.claranet.de> <45085EDF.9020600@levkowetz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbadc1.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tools-discuss@ietf.org Subject: [Ltru] Re: Tiny URLs X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Henrik Levkowetz wrote: [default url1= derived from url2=] > Done. I've also added a symlink [...] > http://www1.tools.ietf.org/tools/rfcdiff.pyht?url2=http://... Great, thanks, test URL: http://www1.tools.ietf.org/tools/rfcdiff.pyht?url2=http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-01.txt&difftype=--hwdiff Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 17:01:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNbr4-0003jg-7L; Wed, 13 Sep 2006 17:01:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNbr2-0003h1-Je for ltru@ietf.org; Wed, 13 Sep 2006 17:01:08 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNbqz-0006O1-7O for ltru@ietf.org; Wed, 13 Sep 2006 17:01:08 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.628.4; Wed, 13 Sep 2006 14:01:04 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Sep 2006 14:01:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] script tag for IPA Date: Wed, 13 Sep 2006 14:00:12 -0700 Message-ID: In-Reply-To: <20060913143839.GK10145@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] script tag for IPA Thread-Index: AcbXQla+F7pARiToTlOYxdeiT9XrMQADjZcA References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> From: Peter Constable To: X-OriginalArrivalTime: 13 Sep 2006 21:01:04.0660 (UTC) FILETIME=[B9E65D40:01C6D777] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At least until an extension was suggested, I had considered getting a script ID added to 15924 for indicating IPA as a variant of Latn (Lipa?). Comparing this versus an extension mechanism, there are pros and cons to consider: - If an extension was used, then any matching processors that do not understand the extension would probably assume that "en" and "en-t-xxxx" were the same -- they have no basis to differentiate other than "there is some unknown difference", and they have no way to know if that unknown difference is relevant or not for matching purposes. But if a script subtag were used, then that is not opaque to any matching processor: matching would always do something reasonable. Extension: 0 Script subtag: 1 - A problem I immediately saw with using a script ID when I first thought of it is that there are probably on the order of 10 important variations of Latin-based phonetic transcription (and who-knows-how-many minor or idiosyncratic variants). It wouldn't make sense to have a script ID for each -- that's really abusing 15924. My thought on dealing with that problem was to have the script ID be neutral with regard to the particular convention of phonetic transcript and simply denote Latin-based phonetic transcriptions (so, "Lphn" rather than "Lipa"?), and then use variant subtags to differentiate between different conventions. Now, clearly an extension would provide a solution to this problem. But so could the alternative I've just described. Extension: 1 Script subtag (+ variants): 2 I can't think of any other benefits of an extension mechanism, certainly not for phonetic transcription, and even for transliterations. It seems to me that transliterations will require the use of a script subtag. E.g. consider Chinese in Wade-Giles. Having a tag along the lines of "zh-t-wadegiles" really isn't sufficient for matching; you'd really want "zh-Latn-t-wadegiles" so that all matching processors will see the *very* important difference between Chinese in Latin script versus Chinese in ideographs. But then, what's the benefit of the singleton "-t"? None that I can see. So, I'm still inclined to handle transcriptions and transliterations using the mechanisms already available to us: script and variant subtags. Peter Constable -----Original Message----- From: John Cowan [mailto:cowan@ccil.org]=20 Sent: Wednesday, September 13, 2006 7:39 AM To: Martin Hosken Cc: ltru@ietf.org Subject: Re: [Ltru] script tag for IPA Martin Hosken scripsit: > I realise that there are probably two choices for this: a new script IPA > or a subscript of Latn. My only thought is that any language may be > written using IPA so if a subscript tag must be registered for each > language, that's a lot of registration. Apart from that I'm easy either > way, I would just like to know what to use. This is part of the general problem of transliteration/transcription, which is not (yet) handled by the RFC 4646 framework. The best permanent answer is probably to create a -t-xxxx standardized extension to 4646, as provided for, and to create a registration authority to register and maintain codes for different transliterations. No one has hitherto stepped forward to become the registration authority, however. Until then, the best solution is probably to keep the transliteration separate from the RFC 4646 language tag, or else to use -x-something as a private-use transliteration subtag. --=20 While staying with the Asonu, I met a man from John Cowan the Candensian plane, which is very much like cowan@ccil.org ours, only more of it consists of Toronto. http://:www.ccil.org/~cowan --Ursula K. Le Guin, Changing Planes _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 17:53:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNcfg-0004TV-2p; Wed, 13 Sep 2006 17:53:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNcff-0004TH-8f for ltru@ietf.org; Wed, 13 Sep 2006 17:53:27 -0400 Received: from white.dnsireland.com ([67.15.182.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNcfW-0004tM-TF for ltru@ietf.org; Wed, 13 Sep 2006 17:53:27 -0400 Received: from [88.81.100.235] (port=37250 helo=[10.0.1.3]) by white.dnsireland.com with esmtpa (Exim 4.52) id 1GNcfE-0003Sd-Ef; Wed, 13 Sep 2006 22:53:06 +0100 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060913202947.GC22114@ccil.org> References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> Date: Wed, 13 Sep 2006 22:52:39 +0100 To: John Cowan From: Michael Everson Subject: Re: [Ltru] script tag for IPA Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - white.dnsireland.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - evertype.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 16:29 -0400 2006-09-13, John Cowan wrote: >Sub-scripts are introduced for practical reasons. Hans and Hant are >just subsets of Hani, but it's handy to be able to differentiate, and the >difference is more like a script difference than it is like anything else. This does not convince me that IPA is some kind of *Latp script variant of Latn. I'm sorry, but it just isn't by everything I know about scripts. Moreover, there are dozens of Latin phonetic alphabets and varieties of them. > > There is also the problem that other Latin phonetic alphabets exist >> which are not IPA. Here's a test. Consider the text [paketilonu]. >> What script is it written in? Latin? The "International Phonetic >> Alphabet"? The "Uralic Phonetic Alphabet"? The "Lepsius Phonetic >> Alphabet"? >> >> Answer: All of the above. Ergo: Latn. > >"What language is 'chat' written in? English? French? Answer: both. >Ergo: Hmmm." Language is a different thing from script. >Is Lisu (in the Fraser orthography) written in Latn? No. >It too uses a small subset of Latin letters plus some novel ones. No. Its characters derive from Latin (just as Thaana letters derive from Arabic digits). But it no longer has case, and indeed Lisu text written in the lower-case versions of the script is illegible to readers. It has become something else. -- Michael Everson * http://www.evertype.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 19:34:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNeEn-0004Bo-HC; Wed, 13 Sep 2006 19:33:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNbaC-0004jX-Ad for ltru@lists.ietf.org; Wed, 13 Sep 2006 16:43:44 -0400 Received: from av9-1-sn2.hy.skanova.net ([81.228.8.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNbaA-0004AV-Tv for ltru@lists.ietf.org; Wed, 13 Sep 2006 16:43:44 -0400 Received: by av9-1-sn2.hy.skanova.net (Postfix, from userid 502) id 49124380B8; Wed, 13 Sep 2006 22:43:42 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av9-1-sn2.hy.skanova.net (Postfix) with ESMTP id 3C54837E4C; Wed, 13 Sep 2006 22:43:42 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id E25FB37E44; Wed, 13 Sep 2006 22:43:41 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1GNba9-0000LX-Mr; Wed, 13 Sep 2006 22:43:41 +0200 Message-ID: <45086D7C.9040208@levkowetz.com> Date: Wed, 13 Sep 2006 22:43:40 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Frank Ellermann References: <20060913153749.GL10145@ccil.org> <450836B0.4010008@yahoo-inc.com> <45083F66.7E6E@xyzzy.claranet.de> <45085EDF.9020600@levkowetz.com> <4508693E.1ECA@xyzzy.claranet.de> In-Reply-To: <4508693E.1ECA@xyzzy.claranet.de> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Wed, 13 Sep 2006 19:33:48 -0400 Cc: ltru@lists.ietf.org, tools-discuss@ietf.org Subject: [Ltru] Re: [Tools-discuss] Re: Tiny URLs X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Frank, on 2006-09-13 22:25 Frank Ellermann said the following: > Henrik Levkowetz wrote: > > [default url1= derived from url2=] >> Done. I've also added a symlink > [...] >> http://www1.tools.ietf.org/tools/rfcdiff.pyht?url2=http://... > > Great, thanks, test URL: > > http://www1.tools.ietf.org/tools/rfcdiff.pyht?url2=http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-01.txt&difftype=--hwdiff I actually shortened it a little bit further just after I sent off the previous : http://tools.ietf.org/rfcdiff?url2=http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-01.txt&difftype=--hwdiff Regards, Henrik _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 19:34:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNeEn-0004Bk-Ee; Wed, 13 Sep 2006 19:33:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNabv-0003YH-NP for ltru@lists.ietf.org; Wed, 13 Sep 2006 15:41:27 -0400 Received: from av6-1-sn3.vrr.skanova.net ([81.228.9.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNabu-0002bY-6l for ltru@lists.ietf.org; Wed, 13 Sep 2006 15:41:27 -0400 Received: by av6-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 5B42037F53; Wed, 13 Sep 2006 21:41:21 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av6-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 4BCE537F48; Wed, 13 Sep 2006 21:41:21 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id C4DD337E47; Wed, 13 Sep 2006 21:41:20 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1GNabn-0006hx-Rv; Wed, 13 Sep 2006 21:41:19 +0200 Message-ID: <45085EDF.9020600@levkowetz.com> Date: Wed, 13 Sep 2006 21:41:19 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Frank Ellermann References: <20060913153749.GL10145@ccil.org> <450836B0.4010008@yahoo-inc.com> <45083F66.7E6E@xyzzy.claranet.de> In-Reply-To: <45083F66.7E6E@xyzzy.claranet.de> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Wed, 13 Sep 2006 19:33:48 -0400 Cc: ltru@lists.ietf.org, tools-discuss@ietf.org Subject: [Ltru] Re: [Tools-discuss] Tiny URLs X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Frank, on 2006-09-13 19:27 Frank Ellermann said the following: > Addison Phillips wrote on tge LTRU list: > >> I note that TinyURL has decided that tools.ietf.org is a >> "frequently spammed" site. I'm going to have to switch to >> del.icio.us or Y!Scuttle for my short URLs.... Hmm - tried to use it just now for a tinyurl to a tools.ietf.org URL, and didn't see any problems... Is it a matter both of target domain and requesting domain? > Sigh, forwarded to the "tools" list, could we get a default > url1= if only url2= is specifified ? The algorithm would be: > > 1: strip and note any extension like ".txt" at the last dot > 2: split version after last hyphen-minus like 03 for "...-03" > 3: concatenate the rest plus version -1 (02) plus extension > to get a default url1. Done. I've also added a symlink so instead of http://www1.tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url2=http://... you can now also use the somewhat shorter http://www1.tools.ietf.org/tools/rfcdiff.pyht?url2=http://... The changes are available on www1.tools.ietf.org now, should be on all servers within an hour. > And maybe let &difftype=--hwdiff be the default, instead of > the side-by-side diff (?) This is less obvious to me... I personally always want the side-by-side diff, but if most people want --hwdiff, we could change. Either way, I've considered adding links to other diff formats at the top of the diff generated, but haven't gone there yet. > It's okay if the tinyurl folks are paranoid, they were or are > blacklisted by wikipedia after some abuse. For redirectors > SURBL offers a way to fight abuse: > Mmm. Thanks. I didn't know about this. Henrik _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 19:47:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNeS1-0000jj-GY; Wed, 13 Sep 2006 19:47:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNeRz-0000ja-9Y for ltru@ietf.org; Wed, 13 Sep 2006 19:47:27 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNeRx-0005J8-Vy for ltru@ietf.org; Wed, 13 Sep 2006 19:47:27 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=fRpVFnytXACFFzE45AJFPy9OSij3/4bGLHVYQZfszr5LhI6J0NVgIz5H9fTCdDx+; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.189.1] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GNeRh-0001Oc-Sm; Wed, 13 Sep 2006 19:47:10 -0400 Message-ID: <002601c6d78f$53ca4d60$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "Michael Everson" References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org><003a01c6d75f$4142ce40$6501a8c0@oemcomputer><30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> Subject: Re: [Ltru] script tag for IPA Date: Wed, 13 Sep 2006 16:49:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7af5f286766aeca17dad6cb6882cc2b460c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.189.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Michael Everson" > To: "John Cowan" > Cc: > Sent: Wednesday, September 13, 2006 2:52 PM > Subject: Re: [Ltru] script tag for IPA .... > >Is Lisu (in the Fraser orthography) written in Latn? > > No. > > >It too uses a small subset of Latin letters plus some novel ones. > > No. Its characters derive from Latin (just as Thaana letters derive > from Arabic digits). But it no longer has case, and indeed Lisu text > written in the lower-case versions of the script is illegible to > readers. It has become something else. ... One could probably make the same argument regarding IPA transcriptions of English, particularly if the transcription is narrow or of a speaker the reader wouldn't understand. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 20:35:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNfCU-0005va-Lc; Wed, 13 Sep 2006 20:35:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNfCT-0005uQ-VU for ltru@ietf.org; Wed, 13 Sep 2006 20:35:29 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNfCS-00021I-I5 for ltru@ietf.org; Wed, 13 Sep 2006 20:35:29 -0400 Received: by nf-out-0910.google.com with SMTP id n15so2039573nfc for ; Wed, 13 Sep 2006 17:35:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=dcksH13AOVZFYkfgmO8pPf3zVlcax0tGdo3csCsV7z9i7iiGENYgD57xYpU6YzhW/DLKd02taXiF5JjSDV4mj+55yyHxbEUtYIGowFiR802E4Pm5TmGVYDhIeRqqVVOGpQobpsdXkWH/wDx/yy4nVEZwJAS1LprefY5gK4lBlws= Received: by 10.49.8.4 with SMTP id l4mr11495041nfi; Wed, 13 Sep 2006 17:35:27 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Wed, 13 Sep 2006 17:35:27 -0700 (PDT) Message-ID: <30b660a20609131735w70b8c5fbh99ff0fa2ddf73087@mail.gmail.com> Date: Wed, 13 Sep 2006 17:35:27 -0700 From: "Mark Davis" To: "Randy Presuhn" Subject: Re: [Ltru] script tag for IPA In-Reply-To: <002601c6d78f$53ca4d60$6501a8c0@oemcomputer> MIME-Version: 1.0 References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <002601c6d78f$53ca4d60$6501a8c0@oemcomputer> X-Google-Sender-Auth: c5f4c1a2b019ca4b X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Michael Everson , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1422591084==" Errors-To: ltru-bounces@ietf.org --===============1422591084== Content-Type: multipart/alternative; boundary="----=_Part_92009_26288971.1158194127145" ------=_Part_92009_26288971.1158194127145 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree. I think the main issue is that what constitutes a script is somewhat fuzzy, and what constitutes a script variant much more so. I don't see any clear reason why Hant (vs Hans) or Latf (vs Latn) is an appropriate distinction, and yet IPA is not. For Hant and IPA, both are choices of repertoires used to represent a written form. Both make a dramatic difference to users. For Latf, it is even less plain why it is somehow deserving of a distinction as a script variant and yet IPA is not. Mark On 9/13/06, Randy Presuhn wrote: > > Hi - > > > From: "Michael Everson" > > To: "John Cowan" > > Cc: > > Sent: Wednesday, September 13, 2006 2:52 PM > > Subject: Re: [Ltru] script tag for IPA > .... > > >Is Lisu (in the Fraser orthography) written in Latn? > > > > No. > > > > >It too uses a small subset of Latin letters plus some novel ones. > > > > No. Its characters derive from Latin (just as Thaana letters derive > > from Arabic digits). But it no longer has case, and indeed Lisu text > > written in the lower-case versions of the script is illegible to > > readers. It has become something else. > ... > > One could probably make the same argument regarding IPA > transcriptions of English, particularly if the transcription is narrow > or of a speaker the reader wouldn't understand. > > Randy > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_92009_26288971.1158194127145 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree. I think the main issue is that what constitutes a script is somewhat fuzzy, and what constitutes a script variant much more so.

I don't see any clear reason why Hant (vs Hans) or Latf (vs Latn) is an appropriate distinction, and yet IPA is not. For Hant and IPA, both are choices of repertoires used to represent a written form. Both make a dramatic difference to users. For Latf, it is even less plain why it is somehow deserving of a distinction as a script variant and yet IPA is not.

Mark

On 9/13/06, Randy Presuhn <randy_presuhn@mindspring.com> wrote:
Hi -

> From: "Michael Everson" <everson@evertype.com>
> To: "John Cowan" <cowan@ccil.org>
> Cc: < ltru@ietf.org>
> Sent: Wednesday, September 13, 2006 2:52 PM
> Subject: Re: [Ltru] script tag for IPA
....
> >Is Lisu (in the Fraser orthography) written in Latn?
>
> No.
>
> >It too uses a small subset of Latin letters plus some novel ones.
>
> No. Its characters derive from Latin (just as Thaana letters derive
> from Arabic digits). But it no longer has case, and indeed Lisu text
> written in the lower-case versions of the script is illegible to
> readers. It has become something else.
...

One could probably make the same argument regarding IPA
transcriptions of English, particularly if the transcription is narrow
or of a speaker the reader wouldn't understand.

Randy


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

------=_Part_92009_26288971.1158194127145-- --===============1422591084== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1422591084==-- From ltru-bounces@ietf.org Wed Sep 13 20:47:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNfOL-0001sW-DS; Wed, 13 Sep 2006 20:47:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNfOK-0001sR-N0 for ltru@ietf.org; Wed, 13 Sep 2006 20:47:44 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNfOJ-0003gR-GY for ltru@ietf.org; Wed, 13 Sep 2006 20:47:44 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GNfOI-0001Px-Qb; Wed, 13 Sep 2006 20:47:42 -0400 Date: Wed, 13 Sep 2006 20:47:42 -0400 To: Michael Everson Subject: Re: [Ltru] script tag for IPA Message-ID: <20060914004742.GR10145@ccil.org> References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Michael Everson scripsit: > No. Its characters derive from Latin (just as Thaana letters derive > from Arabic digits). But it no longer has case, and indeed Lisu text > written in the lower-case versions of the script is illegible to > readers. It has become something else. IPA and its rivals don't have case either, something you have said in the past is fundamental to the nature of the Latin script (and I agree). -- There is / One art John Cowan No more / No less http://www.ccil.org/~cowan To do / All things With art- / Lessness -- Piet Hein _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 22:42:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNhBb-0007pM-GO; Wed, 13 Sep 2006 22:42:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNhBa-0007pH-Nj for ltru@ietf.org; Wed, 13 Sep 2006 22:42:42 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNhBX-0001C6-Cp for ltru@ietf.org; Wed, 13 Sep 2006 22:42:42 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.628.4; Wed, 13 Sep 2006 19:42:38 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Wed, 13 Sep 2006 19:42:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Can't add a Preferred-Value to a redundant tag Date: Wed, 13 Sep 2006 19:42:21 -0700 Message-ID: In-Reply-To: <789E617C880666438EDEE30C2A3E8D10EEF4@mailsrvnt05.enet.sharplabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Can't add a Preferred-Value to a redundant tag Thread-Index: AcbXROFTwCwtfMuMSDmZUpT+Z54sVwAYnr/w References: <789E617C880666438EDEE30C2A3E8D10EEF4@mailsrvnt05.enet.sharplabs.com> From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 14 Sep 2006 02:42:38.0842 (UTC) FILETIME=[71625DA0:01C6D7A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1313939744==" Errors-To: ltru-bounces@ietf.org --===============1313939744== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KUGV0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1jRG9uYWxk LCBJcmEgW21haWx0bzppbWNkb25hbGRAc2hhcnBsYWJzLmNvbV0gDQpTZW50OiBXZWRuZXNkYXks IFNlcHRlbWJlciAxMywgMjAwNiA3OjU3IEFNDQpUbzogJ0RvdWcgRXdlbGwnOyBMVFJVIFdvcmtp bmcgR3JvdXANClN1YmplY3Q6IFJFOiBbTHRydV0gUmU6IENhbid0IGFkZCBhIFByZWZlcnJlZC1W YWx1ZSB0byBhIHJlZHVuZGFudCB0YWcNCg0KKzENCg0KRGVwcmVjYXRlZCBhbmQgUHJlZmVycmVk LVZhbHVlIGZpZWxkcyBjZXJ0YWlubHkgc2hvdWxkDQpjYXJyeSBtb3JlIHdlaWdodCB0aGFuIENv bW1lbnRzIGZpZWxkcy4NCg0KQ2hlZXJzLA0KLSBJcmENCg0KSXJhIE1jRG9uYWxkIChNdXNpY2lh biAvIFNvZnR3YXJlIEFyY2hpdGVjdCkNCkJsdWUgUm9vZiBNdXNpYyAvIEhpZ2ggTm9ydGggSW5j DQpQTyBCb3ggMjIxICBHcmFuZCBNYXJhaXMsIE1JICA0OTgzOQ0KcGhvbmU6ICsxLTkwNi00OTQt MjQzNA0KZW1haWw6IGltY2RvbmFsZEBzaGFycGxhYnMuY29tDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogRG91ZyBFd2VsbCBbbWFpbHRvOmRld2VsbEBhZGVscGhpYS5u ZXRdDQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEzLCAyMDA2IDk6MjAgQU0NCj4gVG86 IExUUlUgV29ya2luZyBHcm91cA0KPiBTdWJqZWN0OiBbTHRydV0gUmU6IENhbid0IGFkZCBhIFBy ZWZlcnJlZC1WYWx1ZSB0byBhIHJlZHVuZGFudCB0YWcNCj4gDQo+IA0KPiBKb2huIENvd2FuIDxj b3dhbiBhdCBjY2lsIGRvdCBvcmc+IHdyb3RlOg0KPiANCj4gPj4gVGFnOiBzZ24tVVMNCj4gPj4g RGVzY3JpcHRpb246IFNpZ24gTGFuZ3VhZ2UgYXMgdXNlZCBpbiB0aGUgVVNBDQo+ID4+IENvbW1l bnRzOiBvcmlnaW5hbGx5IHJlZ2lzdGVyZWQgZm9yIEFTTC4gInNnbi1hc2UiIGlzDQo+ID4+ICAg cmVjb21tZW5kZWQgZm9yIHRoYXQgbWVhbmluZy4NCj4gPg0KPiA+IFRoYXQncyBhcyBtdWNoIGFz IHRvIHNheSB0aGUgb3JpZ2luYWwgbWVhbmluZyBpcyANCj4gZGVwcmVjYXRlZC4gIFNvIGxldCdz IA0KPiA+IHNheSBzbyBvcGVubHksIGFuZCBzdXBwbHkgdGhlIG5ldyB0YWcgZm9yIHRoYXQgbWVh bmluZyB1c2luZyB0aGUgDQo+ID4gbWVjaGFuaXNtIGRlc2lnbmVkIGZvciB0aGF0LCBuYW1lbHkg UHJlZmVycmVkLVZhbHVlLg0KPiANCj4gVG8gY2xhcmlmeTogSSBncmVhdGx5IHByZWZlciB0aGlz IHNvbHV0aW9uLCB3aGVyZWJ5IGlmIHdlIHdhbnQgdG8gDQo+IHJlY29tbWVuZCBvbmUgdGFnZ2lu ZyBzb2x1dGlvbiBvdmVyIGFub3RoZXIsIHdlIHVzZSB0aGUgDQo+IERlcHJlY2F0ZWQgYW5kIA0K PiBQcmVmZXJyZWQtVmFsdWUgZmllbGRzIGludmVudGVkIGZvciB0aGF0IHB1cnBvc2UuICBCdXQg aWYgdGhpcyBpcyANCj4gdW5hY2NlcHRhYmxlIHRvIEFkZGlzb24gYW5kIG90aGVycyBmb3Igc29t ZSByZWFzb24sIEkgY2FuIA0KPiBsaXZlIHdpdGggdGhlIA0KPiBDb21tZW50cyBhcHByb2FjaC4N Cj4gDQo+IC0tDQo+IERvdWcgRXdlbGwNCj4gRnVsbGVydG9uLCBDYWxpZm9ybmlhLCBVU0ENCj4g aHR0cDovL3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLw0KPiBSRkMgNDY0NSAgKiAgVVROICMx NCANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCj4gDQoNCi0tIA0KTm8gdmlydXMgZm91 bmQgaW4gdGhpcyBvdXRnb2luZyBtZXNzYWdlLg0KQ2hlY2tlZCBieSBBVkcgRnJlZSBFZGl0aW9u Lg0KVmVyc2lvbjogNy4xLjQwNSAvIFZpcnVzIERhdGFiYXNlOiAyNjguMTIuMy80NDYgLSBSZWxl YXNlIERhdGU6IDkvMTIvMjAwNg0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KTHRydSBtYWlsaW5nIGxpc3QNCkx0cnVAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg== --===============1313939744== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1313939744==-- From ltru-bounces@ietf.org Wed Sep 13 22:56:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNhOq-0004og-Qh; Wed, 13 Sep 2006 22:56:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNhOp-0004ob-FL for ltru@ietf.org; Wed, 13 Sep 2006 22:56:23 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNhOo-0003Uk-6p for ltru@ietf.org; Wed, 13 Sep 2006 22:56:23 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Wed, 13 Sep 2006 19:56:21 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Sep 2006 19:55:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Can't add a Preferred-Value to a redundant tag Date: Wed, 13 Sep 2006 19:55:49 -0700 Message-ID: In-Reply-To: <20060913161213.GM10145@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Can't add a Preferred-Value to a redundant tag Thread-Index: AcbXT2lsnrPC4OigSV6JIZXxS0YAfwAWLctA References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81><4506D714.4020705@yahoo-inc.com><004301c6d6e1$72276d50$6401a8c0@DGBP7M81><450826A0.2000206@yahoo-inc.com><30b660a20609130901q18d1e97eu2370953c30d34062@mail.gmail.com> <20060913161213.GM10145@ccil.org> From: Peter Constable To: X-OriginalArrivalTime: 14 Sep 2006 02:55:53.0026 (UTC) FILETIME=[4AC13A20:01C6D7A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: John Cowan [mailto:cowan@ccil.org]=20 > > sgn-US should simply mean "sign language as used in the US", which is > > a widening of ASL.=20 > > Well, but does it then exclude documents (videos, e.g.) that are > Canadian in origin? Is "Canadian in origin" the relevant attribute? I could sit in Toronto and create content that is thus Cdn in origin but that uses en-US conventions and so should be tagged en-US; I regularly sit in Seattle and create content that is thus US in origin but that uses en-CA conventions and so should be tagged en-CA. Of course, what matters (which I know you know) is what language variety is reflected in the document, and that potentially there is a Cdn variant of ASL that might be used in some content, so redefining sgn-US from "ASL" (which was a correct attribute of that content) to "signed language as used in the US" (which is not a correct attribute of that content) is resulting in the content becoming inappropriately tagged.=20 Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 23:05:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNhXn-0000R0-WC; Wed, 13 Sep 2006 23:05:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNhXn-0000Qv-Aw for ltru@ietf.org; Wed, 13 Sep 2006 23:05:39 -0400 Received: from smtp1.wsfo.org ([208.145.81.52] helo=smtp2.wsfo.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNhXj-0004qF-Ms for ltru@ietf.org; Wed, 13 Sep 2006 23:05:39 -0400 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp2.wsfo.org (8.13.1/8.13.1) with ESMTP id k8E35LdE020821 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Wed, 13 Sep 2006 23:05:21 -0400 X-Scanned-By: MIMEDefang 2.54 on 172.22.0.52 X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp X-Scanned-By: This message was scanned by MPP Free Edition (www.messagepartners.com)! Received: from [203.154.52.149] (account martin_hosken@sil.org HELO [192.168.1.6]) by mail.link77.net (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 122617061; Wed, 13 Sep 2006 23:05:20 -0400 Message-ID: <4508C6EC.90305@sil.org> Date: Thu, 14 Sep 2006 10:05:16 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Michael Everson Subject: Re: [Ltru] script tag for IPA References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear Michael, > At 16:29 -0400 2006-09-13, John Cowan wrote: >> Sub-scripts are introduced for practical reasons. Hans and Hant are >> just subsets of Hani, but it's handy to be able to differentiate, and >> the >> difference is more like a script difference than it is like anything >> else. > > This does not convince me that IPA is some kind of *Latp script > variant of Latn. I'm sorry, but it just isn't by everything I know > about scripts. Moreover, there are dozens of Latin phonetic alphabets > and varieties of them. Passing all remaining angels, I'll have a go. 1. The IPA is a controlled alphabet so while one can write different types of transcription of the same text (most usually phonetic vs phonemic) it is clear that someone is using the IPA to do it in contradistinction to using a Romanisation or some other phonetic alphabet. 2. Words in Roman script languages are regularly transcribed (not transliterated, this isn't about transliteration) into IPA. Notice that they are different writing systems and while people may come up with different Roman based scripts and transcriptions, they don't, not very often. 3. This is not about trying to come up with a solution for other transcription schemes which are generally recognised to be in a specific script. Thus pinyin is considered a Romanisation of Chinese, but an IPA transcription is not. An IPA transcription is considered to be in IPA not Roman. > >> > There is also the problem that other Latin phonetic alphabets exist >>> which are not IPA. Here's a test. Consider the text [paketilonu]. >>> What script is it written in? Latin? The "International Phonetic >>> Alphabet"? The "Uralic Phonetic Alphabet"? The "Lepsius Phonetic >>> Alphabet"? >>> >>> Answer: All of the above. Ergo: Latn. And what about the 'case' for Cyrllic (same in both) or the 'MONEY' in Greek? Ergo: Latn? I'm not asking for Americanist to be considered its own script, I'm not asking for Pinyin to be its own script. So what is it about the IPA that makes me think of it as a separate script? 1. It is a worldwide standard that dominates its field and is immediately recognisable as such by anyone who can read it, in contrast to reading a Romanisation which is instantly recognisable as being non IPA. I'm not talking about edge cases here, I'm talking about when a linguist sees transcription, they know IPA when they see it. Of course it's not hard to fool someone, but that's not generally the aim. 2. It has subcategorisations within it: phonemic and phonetic being two major writing system categories 3. It isn't used for any orthography since it lacks case. There are no known languages with an IPA orthography, therefore the IPA is a different thing from any orthographic script. 4. Since it is nearly uniquely possible to process text in the IPA without knowledge of its language (at least to a greater extent than for other scripts) it needs to be treated differently from normal Latn orthographies. Warning a user that some text is not in Latn is very important. Well that's my off the cuff attempt and you are welcome to presuppositionally shoot it down (just as a number of people presuppositionally say Lisu is Latin). As others have said, we are dealing in grey areas here and the Latin script has been so productive that when it comes to Latin things get very grey indeed. Yours, Martin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 23:26:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNhru-0000jR-14; Wed, 13 Sep 2006 23:26:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNhrs-0000iA-E1 for ltru@ietf.org; Wed, 13 Sep 2006 23:26:24 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNhrq-00061O-Mg for ltru@ietf.org; Wed, 13 Sep 2006 23:26:24 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Wed, 13 Sep 2006 20:26:22 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Sep 2006 20:26:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] script tag for IPA Date: Wed, 13 Sep 2006 20:25:46 -0700 Message-ID: In-Reply-To: <4508C6EC.90305@sil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] script tag for IPA Thread-Index: AcbXqq2wo7sLgmFOTwmWHNTKiEKfLQAAR0bw References: <450812FA.3040906@sil.org><20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <4508C6EC.90305@sil.org> From: Peter Constable To: X-OriginalArrivalTime: 14 Sep 2006 03:26:22.0205 (UTC) FILETIME=[8D07CAD0:01C6D7AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1239410032==" Errors-To: ltru-bounces@ietf.org --===============1239410032== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTWFydGluIEhvc2tlbiBbbWFpbHRvOm1hcnRpbl9ob3NrZW5Ac2lsLm9yZ10gDQoNCj4g SSdtIG5vdCBhc2tpbmcgZm9yIEFtZXJpY2FuaXN0IHRvIGJlIGNvbnNpZGVyZWQgaXRzIG93biBz Y3JpcHQsIEknbSBub3QNCj4gYXNraW5nIGZvciBQaW55aW4gdG8gYmUgaXRzIG93biBzY3JpcHQu IFNvIHdoYXQgaXMgaXQgYWJvdXQgdGhlIElQQSB0aGF0DQo+IG1ha2VzIG1lIHRoaW5rIG9mIGl0 IGFzIGEgc2VwYXJhdGUgc2NyaXB0Pw0KPg0KPiAxLiBJdCBpcyBhIHdvcmxkd2lkZSBzdGFuZGFy ZCB0aGF0IGRvbWluYXRlcyBpdHMgZmllbGQgYW5kIGlzDQo+IGltbWVkaWF0ZWx5IHJlY29nbmlz YWJsZSBhcyBzdWNoIGJ5IGFueW9uZSB3aG8gY2FuIHJlYWQgaXQNCg0KSU1PIGEgMTU5MjQgSUQg Zm9yIExhdGluLWJhc2VkIHBob25ldGljIHRyYW5zY3JpcHRpb24gd291bGQgYmUgYXBwcm9wcmlh dGUuIEJ1dCBJTU8gaXQgd291bGQgbm90IGJlIGFwcHJvcHJpYXRlIHRvIGFzc2lnbiAxNTkyNCBJ RCBzcGVjaWZpYyB0byBzb21lIHN5c3RlbXMgb2YgTGF0aW4tYmFzZWQgcGhvbmV0aWMgdHJhbnNj cmlwdGlvbiBidXQgbm90IG90aGVycy4gTGF0aW4tYmFzZWQgcGhvbmV0aWMgdHJhbnNjcmlwdGlv bnMgc2hvdWxkIGhhdmUgb25lIGNvbnNpc3RlbnQgbWVjaGFuaXNtIG9mIHN1cHBvcnQgaW4gSUVU RiBsYW5ndWFnZSB0YWdzLg0KDQpNeSB2b3RlIGlzIHRvIGFkZCBhIHNjcmlwdCB2YXJpYW50IElE ICJMcGhuIiBvciAiTGF0cCIgdG8gMTU5MjQgYW5kIHRoZW4gcmVnaXN0ZXIgdmFyaWFudCBzdWJ0 YWdzIGRlbm90aW5nIHNwZWNpZmljIHN5c3RlbXMgb2YgcGhvbmV0aWMgdHJhbnNjcmlwdGlvbiBl YWNoIGxpc3RpbmcgIkxwaG4iIChvciAiTGF0cCIpIGFzIGEgcHJlZml4LiBUaHVzLCB3ZSdkIGhh dmUgdGFncyBhbG9uZyB0aGUgbGluZXMgb2YgImVuLUxwaG4taW50bHBob24iLCAiY2hyLUxwaG4t YW1lcnBob24iLCAiYmFkLUxwaG4tZG9rZXBob24iLiBUaGlzIGFsbG93cyANCg0KLSBtYXRjaGlu ZyBjb250ZW50IGluIHNvbWUgbGFuZ3VhZ2Ugd2hldGhlciB1c2luZyBwcmFjdGljYWwgb3J0aG9n cmFwaHkgb3IgcGhvbmV0aWMgdHJhbnNjcmlwdGlvbg0KLSBtYXRjaGluZyBjb250ZW50IGluIHNv bWUgbGFuZ3VhZ2UgaW4gcGhvbmV0aWMgdHJhbnNjcmlwdGlvbiBvZiBhbnkga2luZA0KLSBtYXRj aGluZyBjb250ZW50IGluIHNvbWUgbGFuZ3VhZ2UgaW4gc29tZSBzcGVjaWZpYyBzeXN0ZW0gb2Yg cGhvbmV0aWMgdHJhbnNjcmlwdGlvbg0KDQpBbGwgb2YgdGhlc2UgYXJlIHVzZWZ1bC4NCg0KDQpQ ZXRlciBDb25zdGFibGUNCg== --===============1239410032== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1239410032==-- From ltru-bounces@ietf.org Wed Sep 13 23:31:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNhx4-0003SA-Mn; Wed, 13 Sep 2006 23:31:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNhx2-0003Ry-Nr for ltru@ietf.org; Wed, 13 Sep 2006 23:31:44 -0400 Received: from smtp1.wsfo.org ([208.145.81.52] helo=smtp2.wsfo.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNhx1-0006WS-ES for ltru@ietf.org; Wed, 13 Sep 2006 23:31:44 -0400 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp2.wsfo.org (8.13.1/8.13.1) with ESMTP id k8E3VeLs021792 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Wed, 13 Sep 2006 23:31:43 -0400 X-Scanned-By: MIMEDefang 2.54 on 172.22.0.52 X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp X-Scanned-By: This message was scanned by MPP Free Edition (www.messagepartners.com)! Received: from [203.154.52.149] (account martin_hosken@sil.org HELO [192.168.1.6]) by mail.link77.net (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 122618457; Wed, 13 Sep 2006 23:31:42 -0400 Message-ID: <4508CD1A.9050405@sil.org> Date: Thu, 14 Sep 2006 10:31:38 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] script tag for IPA References: <450812FA.3040906@sil.org><20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <4508C6EC.90305@sil.org> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear Peter, > My vote is to add a script variant ID "Lphn" or "Latp" to 15924 and then register variant subtags denoting specific systems of phonetic transcription each listing "Lphn" (or "Latp") as a prefix. Thus, we'd have tags along the lines of "en-Lphn-intlphon", "chr-Lphn-amerphon", "bad-Lphn-dokephon". This allows > > - matching content in some language whether using practical orthography or phonetic transcription > - matching content in some language in phonetic transcription of any kind > - matching content in some language in some specific system of phonetic transcription > > All of these are useful. > My understanding of RFC 4646 is that extensions like intlphon need to be registered *per language*. There seems to be no concept of script extensions. So either we have to hide it behind a chr-Lphn-t-ipa-phn (ipa phonemic) or do something else? But I may have misread the RFC. Yours, Martin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 13 23:49:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNiET-00022a-Q4; Wed, 13 Sep 2006 23:49:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNiES-00022V-O8 for ltru@ietf.org; Wed, 13 Sep 2006 23:49:44 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNiER-0007fa-Fb for ltru@ietf.org; Wed, 13 Sep 2006 23:49:44 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Wed, 13 Sep 2006 20:49:43 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Wed, 13 Sep 2006 20:49:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] script tag for IPA Date: Wed, 13 Sep 2006 20:49:27 -0700 Message-ID: In-Reply-To: <4508CD1A.9050405@sil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] script tag for IPA Thread-Index: AcbXrk7WYnwzjgOPQO+iAQlhHZiQEwAAaHsQ References: <450812FA.3040906@sil.org><20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <4508C6EC.90305@sil.org> <4508CD1A.9050405@sil.org> From: Peter Constable To: X-OriginalArrivalTime: 14 Sep 2006 03:49:42.0921 (UTC) FILETIME=[CFEC1790:01C6D7B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1618466349==" Errors-To: ltru-bounces@ietf.org --===============1618466349== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTWFydGluIEhvc2tlbiBbbWFpbHRvOm1hcnRpbl9ob3NrZW5Ac2lsLm9yZ10gDQoNCj4g TXkgdW5kZXJzdGFuZGluZyBvZiBSRkMgNDY0NiBpcyB0aGF0IGV4dGVuc2lvbnMgbGlrZSANCj4g aW50bHBob24gbmVlZCB0byBiZSByZWdpc3RlcmVkICpwZXIgbGFuZ3VhZ2UqLiBUaGVyZSANCj4g c2VlbXMgdG8gYmUgbm8gY29uY2VwdCBvZiBzY3JpcHQgZXh0ZW5zaW9ucy4gU28gZWl0aGVyIA0K PiB3ZSBoYXZlIHRvIGhpZGUgaXQgYmVoaW5kIGEgY2hyLUxwaG4tdC1pcGEtcGhuDQo+IChpcGEg cGhvbmVtaWMpIG9yIGRvIHNvbWV0aGluZyBlbHNlPyANCg0KV2UncmUgaW4gdGhlIHByb2Nlc3Mg b2YgZHJhZnRpbmcgYSByZXZpc2VkIFJGQywgYW5kIG9uZSBvZiB0aGUgaXNzdWVzIGluIHRoZSBj aGFydGVyIHRvIGJlIGFkZHJlc3NlZCBpcyBpbiB0aGlzIHdvcmsgaXMgaG93IHRvIGhhbmRsZSB0 cmFuc2NyaXB0aW9ucyBhbmQgdHJhbnNsaXRlcmF0aW9ucy4gV2UgY2FuIG1ha2UgdGhlIG5ldyBS RkMgZG8gd2hhdCB3ZSB0aGluayB3ZSBuZWVkIGl0IHRvOyB3ZSdyZSBub3QgY29uc3RyYWluZWQg YnkgdGhlIGN1cnJlbnQgUkZDIHNvIGxvbmcgYXMgd2UgZG9uJ3QgaW50cm9kdWNlIGEgY2hhbmdl IHRoYXQgd291bGQgYnJlYWsgZXhpc3RpbmcgcHJvY2Vzc2VzIG9yIGludmFsaWRhdGUgZXhpc3Rp bmcgdGFncy4NCg0KU28sIGlmIHdlIGRldGVybWluZSB0aGF0IHRoZSBiZXN0IHNvbHV0aW9uIHRv IHRyYW5zY3JpcHRpb25zIGFuZCB0cmFuc2xpdGVyYXRpb25zIGludm9sdmVzIHVzZSBvZiB2YXJp YW50IHN1YnRhZ3MgdGhhdCBhcmUgY29uc3RyYWluZWQgdG8gYSBzY3JpcHQgYnV0IG5vdCBhIGxh bmd1YWdlLCB0aGVuIHdlIHNpbXBseSBuZWVkIHRvIGZpZ3VyZSBvdXQgd2hhdCByZXZpc2lvbnMg dG8gdGhlIGRvYyBzaG91bGQgYmUgbWFkZSB0byBhY2hpZXZlIHRoYXQuDQoNCg0KDQpQZXRlciBD b25zdGFibGUNCg== --===============1618466349== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1618466349==-- From ltru-bounces@ietf.org Wed Sep 13 23:57:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNiLf-0004yK-6i; Wed, 13 Sep 2006 23:57:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNiLd-0004yC-UM for ltru@ietf.org; Wed, 13 Sep 2006 23:57:09 -0400 Received: from smtp1.wsfo.org ([208.145.81.52] helo=smtp2.wsfo.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNiLY-0008FR-Lm for ltru@ietf.org; Wed, 13 Sep 2006 23:57:09 -0400 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp2.wsfo.org (8.13.1/8.13.1) with ESMTP id k8E3v4L3022646 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Wed, 13 Sep 2006 23:57:04 -0400 X-Scanned-By: MIMEDefang 2.54 on 172.22.0.52 X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp X-Scanned-By: This message was scanned by MPP Free Edition (www.messagepartners.com)! Received: from [203.150.136.129] (account martin_hosken@sil.org HELO [192.168.1.6]) by mail.link77.net (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 122619915; Wed, 13 Sep 2006 23:57:03 -0400 Message-ID: <4508D30B.6030605@sil.org> Date: Thu, 14 Sep 2006 10:56:59 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] script tag for IPA References: <450812FA.3040906@sil.org><20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <4508C6EC.90305@sil.org> <4508CD1A.9050405@sil.org> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear Peter, > We're in the process of drafting a revised RFC, and one of the issues in the charter to be addressed is in this work is how to handle transcriptions and transliterations. We can make the new RFC do what we think we need it to; we're not constrained by the current RFC so long as we don't introduce a change that would break existing processes or invalidate existing tags. > > So, if we determine that the best solution to transcriptions and transliterations involves use of variant subtags that are constrained to a script but not a language, then we simply need to figure out what revisions to the doc should be made to achieve that. > As part of that, may I request that the full tag be parsable into language and script components without recourse to a dictionary. For example that script components are easily identifiable by being say first char capitalised. The reason for this is that there are generic processes that while not needing to know what language some text in, do need to know about script information. This of course also implies a set of rules to turn language + script information back into a full tag. TIA, Martin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 00:17:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNiex-000520-Jv; Thu, 14 Sep 2006 00:17:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNiex-00051v-5G for ltru@ietf.org; Thu, 14 Sep 2006 00:17:07 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNiev-0003Ty-Ta for ltru@ietf.org; Thu, 14 Sep 2006 00:17:07 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.628.4; Wed, 13 Sep 2006 21:17:05 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Wed, 13 Sep 2006 21:17:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] script tag for IPA Date: Wed, 13 Sep 2006 21:16:39 -0700 Message-ID: In-Reply-To: <4508D30B.6030605@sil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] script tag for IPA Thread-Index: AcbXsdvRCJ5LE+XwRQi1arF0IpXNrQAAln+w References: <450812FA.3040906@sil.org><20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <4508C6EC.90305@sil.org> <4508CD1A.9050405@sil.org> <4508D30B.6030605@sil.org> From: Peter Constable To: X-OriginalArrivalTime: 14 Sep 2006 04:17:05.0626 (UTC) FILETIME=[A30CFBA0:01C6D7B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1975298187==" Errors-To: ltru-bounces@ietf.org --===============1975298187== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTWFydGluIEhvc2tlbiBbbWFpbHRvOm1hcnRpbl9ob3NrZW5Ac2lsLm9yZ10gDQoNCj4g QXMgcGFydCBvZiB0aGF0LCBtYXkgSSByZXF1ZXN0IHRoYXQgdGhlIGZ1bGwgdGFnIGJlIHBhcnNh YmxlIGludG8NCj4gbGFuZ3VhZ2UgYW5kIHNjcmlwdCBjb21wb25lbnRzIHdpdGhvdXQgcmVjb3Vy c2UgdG8gYSBkaWN0aW9uYXJ5LiBGb3INCj4gZXhhbXBsZSB0aGF0IHNjcmlwdCBjb21wb25lbnRz IGFyZSBlYXNpbHkgaWRlbnRpZmlhYmxlIGJ5IGJlaW5nIHNheQ0KPiBmaXJzdCBjaGFyIGNhcGl0 YWxpc2VkLg0KDQpQbGVhc2UgcmVhZCBSRkM0NjQ2LiBUaGUgc3ludGF4IGlzIGhpZ2hseSBwYXJz YWJsZSwgYW5kIHlvdSBjYW4gYWxyZWFkeSByZWNvZ25pemUgYSBzY3JpcHQgc3VidGFnIHVuYW1i aWd1b3VzbHkuIFRoYXQgd2lsbCBub3QgY2hhbmdlIGluIFJGQzQ2NDZiaXMgLS0gZ3VhcmFudGVl ZC4NCg0KDQoNClBldGVyIENvbnN0YWJsZQ0K --===============1975298187== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1975298187==-- From ltru-bounces@ietf.org Thu Sep 14 00:22:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNijj-0006nU-Sv; Thu, 14 Sep 2006 00:22:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNiji-0006nB-EF for ltru@ietf.org; Thu, 14 Sep 2006 00:22:02 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNijh-00058v-7O for ltru@ietf.org; Thu, 14 Sep 2006 00:22:02 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GNijg-00075m-UL; Thu, 14 Sep 2006 00:22:00 -0400 Date: Thu, 14 Sep 2006 00:22:00 -0400 To: Martin Hosken Subject: Re: [Ltru] script tag for IPA Message-ID: <20060914042200.GT10145@ccil.org> References: <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <4508C6EC.90305@sil.org> <4508CD1A.9050405@sil.org> <4508D30B.6030605@sil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4508D30B.6030605@sil.org> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Hosken scripsit: > As part of that, may I request that the full tag be parsable into > language and script components without recourse to a dictionary. For > example that script components are easily identifiable by being say > first char capitalised. The reason for this is that there are generic > processes that while not needing to know what language some text in, do > need to know about script information. This of course also implies a set > of rules to turn language + script information back into a full tag. This is already so. You can identify the subtags in a RFC 4646 tag (excepting the few grandfathered ones) by a combination of subtag length and the binary features +/-initial and +/-digits. For example, a 4-character subtag that is -initial and -digits is a script; an +initial tag is always a language regardless of other features. Assembling a tag from subtags is even simpler: the order is always language-script-region-variant. -- Unless it was by accident that I had John Cowan offended someone, I never apologized. cowan@ccil.org --Quentin Crisp http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 00:35:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNiwb-0003a8-Jh; Thu, 14 Sep 2006 00:35:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNiwa-0003a3-Pq for ltru@ietf.org; Thu, 14 Sep 2006 00:35:20 -0400 Received: from smtp1.wsfo.org ([208.145.81.52] helo=smtp2.wsfo.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNiwZ-0007X1-HA for ltru@ietf.org; Thu, 14 Sep 2006 00:35:20 -0400 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp2.wsfo.org (8.13.1/8.13.1) with ESMTP id k8E4ZCXv023996 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Thu, 14 Sep 2006 00:35:12 -0400 X-Scanned-By: MIMEDefang 2.54 on 172.22.0.52 X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp X-Scanned-By: This message was scanned by MPP Free Edition (www.messagepartners.com)! Received: from [203.150.136.129] (account martin_hosken@sil.org HELO [192.168.1.6]) by mail.link77.net (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 122621869; Thu, 14 Sep 2006 00:35:12 -0400 Message-ID: <4508DBFB.8030106@sil.org> Date: Thu, 14 Sep 2006 11:35:07 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] script tag for IPA References: <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <4508C6EC.90305@sil.org> <4508CD1A.9050405@sil.org> <4508D30B.6030605@sil.org> <20060914042200.GT10145@ccil.org> In-Reply-To: <20060914042200.GT10145@ccil.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear John, >> As part of that, may I request that the full tag be parsable into >> language and script components without recourse to a dictionary. For >> example that script components are easily identifiable by being say >> first char capitalised. The reason for this is that there are generic >> processes that while not needing to know what language some text in, do >> need to know about script information. This of course also implies a set >> of rules to turn language + script information back into a full tag. >> > > This is already so. You can identify the subtags in a RFC 4646 tag > (excepting the few grandfathered ones) by a combination of subtag length > and the binary features +/-initial and +/-digits. > > For example, a 4-character subtag that is -initial and -digits is a > script; an +initial tag is always a language regardless of other features. > > Assembling a tag from subtags is even simpler: the order is always > language-script-region-variant. > I was thinking more about script variant subtags. Thus splitting en-Latn-UK-glasgow-Ipapt into en-UK-glasgow and Latn-Ipapt and then putting it back together without having to know much about glasgow or Ipapt. Or should that be en-Latn-UK-Ipapt-glasgow? (Glaswegian English written in IPA phonetically). Yours, Martin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 00:44:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNj5A-0006q4-Gr; Thu, 14 Sep 2006 00:44:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNj58-0006pz-IT for ltru@ietf.org; Thu, 14 Sep 2006 00:44:10 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNj56-0000wx-5m for ltru@ietf.org; Thu, 14 Sep 2006 00:44:10 -0400 Received: from [10.72.72.6] (snvvpn1-10-72-72-c6.corp.yahoo.com [10.72.72.6]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8E4i6Oa012586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Sep 2006 21:44:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=2rxIBf33SiIx4o9ZwgySdf5rMwe2voxAP8fG8raYBJFluEFmA/PzQ6OpWVquEhQY Message-ID: <4508DE16.3080607@yahoo-inc.com> Date: Wed, 13 Sep 2006 21:44:06 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] script tag for IPA References: <450812FA.3040906@sil.org><20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <4508C6EC.90305@sil.org> <4508CD1A.9050405@sil.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > > So, if we determine that the best solution to transcriptions > and transliterations involves use of variant subtags that > are constrained to a script but not a language, then we > simply need to figure out what revisions to the doc > should be made to achieve that. ::shudder:: I think that's a perfectly awful idea for how to handle transcription/transliteration. I think extensions are entirely the best way to handle this very specialized kind of language identification. However, only a very tiny modification would be necessary for what you desire. Currently we use Basic Language Ranges for Prefix. Changing to Extended Language Range would do what you want: Type: variant Subtag: polyton Prefix: *-Grek Comments: This variant can also be applied to languages with a Suppress-Script of 'Grek' If we relax the prefix check on variants, this works functionally too. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 00:59:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNjK8-0004Hl-Jo; Thu, 14 Sep 2006 00:59:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNjK6-0004Hg-U3 for ltru@ietf.org; Thu, 14 Sep 2006 00:59:38 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNjK5-0005dK-Lf for ltru@ietf.org; Thu, 14 Sep 2006 00:59:38 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Wed, 13 Sep 2006 21:59:37 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Wed, 13 Sep 2006 21:59:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] script tag for IPA Date: Wed, 13 Sep 2006 21:58:37 -0700 Message-ID: In-Reply-To: <4508DBFB.8030106@sil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] script tag for IPA Thread-Index: AcbXtzRcUO3Vej7mQNeA13X8x75YYAAApj4w References: <003a01c6d75f$4142ce40$6501a8c0@oemcomputer><30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com><4508C6EC.90305@sil.org><4508CD1A.9050405@sil.org><4508D30B.6030605@sil.org> <20060914042200.GT10145@ccil.org> <4508DBFB.8030106@sil.org> From: Peter Constable To: X-OriginalArrivalTime: 14 Sep 2006 04:59:37.0332 (UTC) FILETIME=[93FC6B40:01C6D7BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1073082153==" Errors-To: ltru-bounces@ietf.org --===============1073082153== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTWFydGluIEhvc2tlbiBbbWFpbHRvOm1hcnRpbl9ob3NrZW5Ac2lsLm9yZ10gDQoNCj4g SSB3YXMgdGhpbmtpbmcgbW9yZSBhYm91dCBzY3JpcHQgdmFyaWFudCBzdWJ0YWdzLg0KDQpPSywg cmUgbXkgZWFybGllciBtYWlsIGNvbnNpZGVyaW5nIHByb3MgYW5kIGNvbnMgb2YgYSAtdCBleHRl bnNpb24gdnMgdXNpbmcgc2NyaXB0IHN1YnRhZyArIHZhcmlhbnRzLCB0aGlzIGlzIHNvbWV0aGlu ZyB0aGF0IHdvdWxkIGJlIHByb3ZpZGVkIGJ5IGFuIGV4dGVuc2lvbiBidXQgbm90IHJlYWRpbHkg dXNpbmcgc2NyaXB0ICsgdmFyaWFudHMgKHVubGVzcyB3ZSBpbnRyb2R1Y2VkIHNvbWUgYWQgaG9j IGNvbnZlbnRpb25zLCBzdWNoIGFzIHNjcmlwdCB2YXJpYW50cyBhbHdheXMgYmVnaW4gInhzLi4u Iiwgb3IgYSBzcGVjaWFsIHZhcmlhbnQgc3VidGFnICJzY3JpcHRzIiBkZWxpbWl0cyBzY3JpcHQt dmFyaWFudCBzdWJ0YWdzIGZyb20gbGFuZ3VhZ2UtdmFyaWFudCBzdWJ0YWdzIC0tIGEgc2luZ2xl dG9uIGluIGRpc2d1aXNlKS4NCg0KU286DQoNCkV4dGVuc2lvbjogMg0KU2NyaXB0IHN1YnRhZyAr IHZhcmlhbnRzOiAyDQoNCg0KDQpQZXRlciBDb25zdGFibGUNCg== --===============1073082153== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1073082153==-- From ltru-bounces@ietf.org Thu Sep 14 01:04:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNjOe-0006QA-Dl; Thu, 14 Sep 2006 01:04:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNjOd-0006Q0-HL for ltru@ietf.org; Thu, 14 Sep 2006 01:04:19 -0400 Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNjOc-0006BC-65 for ltru@ietf.org; Thu, 14 Sep 2006 01:04:19 -0400 Received: from spam.cs.tut.fi (spam-eth1.lintula [10.11.18.2]) by mail.cs.tut.fi (Postfix) with ESMTP id 5697D1125 for ; Thu, 14 Sep 2006 08:04:13 +0300 (EEST) Received: from mail.cs.tut.fi ([130.230.4.42]) by spam.cs.tut.fi (spam.cs.tut.fi [10.11.18.2]) (amavisd-new, port 10024) with ESMTP id 04978-02-6 for ; Thu, 14 Sep 2006 08:04:12 +0300 (EEST) Received: from mustatilhi.cs.tut.fi (mustatilhi.cs.tut.fi [130.230.4.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id 7019012F2 for ; Thu, 14 Sep 2006 08:00:48 +0300 (EEST) Date: Thu, 14 Sep 2006 08:00:48 +0300 (EEST) From: "Jukka K. Korpela" To: ltru@ietf.org Subject: Re: [Ltru] script tag for IPA In-Reply-To: <20060914004742.GR10145@ccil.org> Message-ID: References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <20060914004742.GR10145@ccil.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: amavisd-new at cs.tut.fi X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Wed, 13 Sep 2006, John Cowan wrote: > IPA and its rivals don't have case either, something you have said > in the past is fundamental to the nature of the Latin script (and > I agree). Under such an interpretation, Latin was not written using the Latin script before the middle ages. Actually, even noways, Latin is often written unicamerally, in all uppercase or in all lowercase. The concept of "script" as in "the Latin script", "the Cyrillic script", etc., is a very high-level abstraction. The way I see things, a "script" in that sense is a collection of writing systems that share are common origin and have not diverged too much as regards to their basic symbols. The invention of lowercase letters vs. uppercase letters does not seem to constitute a fundamental phenomenon in this respect. The nature of IPA writing can be interpreted in different ways: it could be treated as being based on the Latin script but with a very large number of additions (and somewhat artificial changes to meanings of letters), or as a separate script of eclectic origin. The latter would be more natural. In particular, I can take, say, a Russian word and write it normally (using Cyrillic letters), or as transliterated (romanized, using Latin letters) according to some scheme, or phonetically using IPA, according to some pronunciation. Wouldn't it be appropriate these as using three different scripts? The fact that some IPA letters have been coded in Unicode as identical to some Latin letters was just a practical choice and does not change the identity of the script - any more than the identity of the Cyrillic script would have been changed if Cyrillic "A" had been encoded as the same as Latin "A", etc. -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 04:13:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNmLm-0000HG-R9; Thu, 14 Sep 2006 04:13:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNmLm-0000EO-5S for ltru@ietf.org; Thu, 14 Sep 2006 04:13:34 -0400 Received: from white.dnsireland.com ([67.15.182.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNmGo-0001Hf-IF for ltru@ietf.org; Thu, 14 Sep 2006 04:08:27 -0400 Received: from [88.81.100.235] (port=42693 helo=[10.0.1.3]) by white.dnsireland.com with esmtpa (Exim 4.52) id 1GNmGi-0008Qv-08; Thu, 14 Sep 2006 09:08:20 +0100 Mime-Version: 1.0 Message-Id: In-Reply-To: <4508C6EC.90305@sil.org> References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <4508C6EC.90305@sil.org> Date: Thu, 14 Sep 2006 09:07:35 +0100 To: Martin Hosken From: Michael Everson Subject: Re: [Ltru] script tag for IPA Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - white.dnsireland.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - evertype.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I think that all of these transcription forms are equivalent. en-Latn-ipalpha en-Latn-lepsius en-Latn-webster en-Latn-johnson en-Latn-encarta en-Latn-duden zh-Latn-pinyin zh-Latn-wadegiles zh-Latn-ipalpha So to reiterate, I am not convinced that IPA Latin orthography differs from Library of Congress Latin orthography or Chicago Manual of Style Latin orthography (for Russian or for Georgian transcription, for instance) and so it seems to me that those orthographies are all subtags of Latin, not a primary variant like Latf and Latg. Transcription of Chinese in Pinyin isn't materially different from transcription of Chinese in IPA. -- Michael Everson * http://www.evertype.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 04:13:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNmM1-0000Ta-MC; Thu, 14 Sep 2006 04:13:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNmM0-0000Qw-C9 for ltru@ietf.org; Thu, 14 Sep 2006 04:13:48 -0400 Received: from white.dnsireland.com ([67.15.182.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNm7e-0000GY-Ee for ltru@ietf.org; Thu, 14 Sep 2006 03:59:00 -0400 Received: from [88.81.100.235] (port=42431 helo=[10.0.1.3]) by white.dnsireland.com with esmtpa (Exim 4.52) id 1GNm7K-0007aY-Iq; Thu, 14 Sep 2006 08:58:39 +0100 Mime-Version: 1.0 Message-Id: In-Reply-To: <30b660a20609131735w70b8c5fbh99ff0fa2ddf73087@mail.gmail.com> References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <002601c6d78f$53ca4d60$6501a8c0@oemcomputer> <30b660a20609131735w70b8c5fbh99ff0fa2ddf73087@mail.gmail.com> Date: Thu, 14 Sep 2006 08:53:41 +0100 To: "Mark Davis" , "Randy Presuhn" From: Michael Everson Subject: Re: [Ltru] script tag for IPA Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - white.dnsireland.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - evertype.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 17:35 -0700 2006-09-13, Mark Davis wrote: >I agree. I think the main issue is that what=20 >constitutes a script is somewhat fuzzy, and what=20 >constitutes a script variant much more so. > >I don't see any clear reason why Hant (vs Hans)=20 >or Latf (vs Latn) is an appropriate distinction,=20 >and yet IPA is not. For Hant and IPA, both are=20 >choices of repertoires used to represent a=20 >written form. Both make a dramatic difference to=20 >users. For Latf, it is even less plain why it is=20 >somehow deserving of a distinction as a script=20 >variant and yet IPA is not. Latf and Latg are distinguished in ISO 15924=20 because Librarians (it is a TC46 standard) may=20 need to distinguish a published edition of "Der=20 Blechtrommel" or "An tOile=E1nach" (in terms of=20 accessibility or legibility to modern readers) as=20 being in Roman or Fraktur/Gaelic script. These=20 script variants each cover a range of related=20 font styles which are distinct from Roman Latin. Polytonic Greek uses the same script as Monotonic=20 Greek. It uses all the same letters, alpha to=20 omega, plus PSILI and DASIA and PERISPOMENI and=20 VARIA and YPIGEGRAMMENI and PROSGEGRAMMENI. Right=20 there. You're deceiving yourself by the fact that=20 the U+1F00 block has a lot of glyphs in it that=20 there is some "script" difference because you=20 think this might make some sort of programming=20 easier. That is my guess anyway. Because=20 Monotonic + 6 additional Greek characters does=20 not =3D a script variant like Latf or Latg. The=20 script variants are not orthographies. ISO 15924=20 isn't designed for that kind of distinction, and=20 it would be wrong to introduces such a practice. With RFC 4646, however, you could distinguish the=20 orthographies with *Grek-polyton and=20 *Grek-monoton if you wished. Similarly, IPA is an *orthography* which uses=20 Latin letters, and it is not a script. Could you=20 not use *Latn-ipalpha? Because as far as I can=20 see that is what you want anyway. Here's why. Russian is your language. You can write ru-Cyrl.=20 You can write ru-Latn. Ah, but ru-Latn refers to=20 some usual orthographic form of Russian in Latin=20 letters. You might need to make this more=20 precise. ru-Latn-libcong or ru-Latn-ipalpha. Or=20 ru-Latn-uralphon, or ru-Latn-lepsius, or=20 ru-Latn-chicago etc etc etc. -- Michael Everson * http://www.evertype.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 06:41:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNofD-0008Fk-Sl; Thu, 14 Sep 2006 06:41:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNofB-0008FP-4v for ltru@ietf.org; Thu, 14 Sep 2006 06:41:45 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNof8-0006VC-7i for ltru@ietf.org; Thu, 14 Sep 2006 06:41:45 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8EAfW5f021059 for ; Thu, 14 Sep 2006 19:41:32 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 036b_960cfdd4_43dd_11db_8775_0014221f2a2d; Thu, 14 Sep 2006 19:41:31 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35481) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 14 Sep 2006 19:41:39 +0900 Message-Id: <6.0.0.20.2.20060914173957.08325a40@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 14 Sep 2006 17:44:12 +0900 To: Michael Everson , "Mark Davis" , "Randy Presuhn" From: Martin Duerst Subject: Re: [Ltru] script tag for IPA In-Reply-To: References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <002601c6d78f$53ca4d60$6501a8c0@oemcomputer> <30b660a20609131735w70b8c5fbh99ff0fa2ddf73087@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org As a technical contributor, I think that the Greek monotonic/polytonic distinction does not merit a script distinction, but that IPA can easily be handled as a script. Good arguments for handling IPA that way have been brought up by many people, I don't want to repeat them. Given my above judgement, I don't understand why e.g. the mail below talks about Greek in detail while the mail it responds to didn't mention Greek at all. Regards, Martin. At 16:53 06/09/14, Michael Everson wrote: >At 17:35 -0700 2006-09-13, Mark Davis wrote: >>I agree. I think the main issue is that what constitutes a script is somewhat fuzzy, and what constitutes a script variant much more so. >> >>I don't see any clear reason why Hant (vs Hans) or Latf (vs Latn) is an appropriate distinction, and yet IPA is not. For Hant and IPA, both are choices of repertoires used to represent a written form. Both make a dramatic difference to users. For Latf, it is even less plain why it is somehow deserving of a distinction as a script variant and yet IPA is not. > >Latf and Latg are distinguished in ISO 15924 because Librarians (it is a TC46 standard) may need to distinguish a published edition of "Der Blechtrommel" or "An tOile$BaO(Bach" (in terms of accessibility or legibility to modern readers) as being in Roman or Fraktur/Gaelic script. These script variants each cover a range of related font styles which are distinct from Roman Latin. > >Polytonic Greek uses the same script as Monotonic Greek. It uses all the same letters, alpha to omega, plus PSILI and DASIA and PERISPOMENI and VARIA and YPIGEGRAMMENI and PROSGEGRAMMENI. Right there. You're deceiving yourself by the fact that the U+1F00 block has a lot of glyphs in it that there is some "script" difference because you think this might make some sort of programming easier. That is my guess anyway. Because Monotonic + 6 additional Greek characters does not = a script variant like Latf or Latg. The script variants are not orthographies. ISO 15924 isn't designed for that kind of distinction, and it would be wrong to introduces such a practice. > >With RFC 4646, however, you could distinguish the orthographies with *Grek-polyton and *Grek-monoton if you wished. > >Similarly, IPA is an *orthography* which uses Latin letters, and it is not a script. Could you not use *Latn-ipalpha? Because as far as I can see that is what you want anyway. Here's why. > >Russian is your language. You can write ru-Cyrl. You can write ru-Latn. Ah, but ru-Latn refers to some usual orthographic form of Russian in Latin letters. You might need to make this more precise. ru-Latn-libcong or ru-Latn-ipalpha. Or ru-Latn-uralphon, or ru-Latn-lepsius, or ru-Latn-chicago etc etc etc. >-- >Michael Everson * http://www.evertype.com > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 06:41:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNofD-0008Fg-Pw; Thu, 14 Sep 2006 06:41:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNofB-0008FK-1M for ltru@ietf.org; Thu, 14 Sep 2006 06:41:45 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNof8-0006VH-7i for ltru@ietf.org; Thu, 14 Sep 2006 06:41:45 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8EAfX3U021064 for ; Thu, 14 Sep 2006 19:41:33 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 045d_96f59986_43dd_11db_9a63_0014221fa3c9; Thu, 14 Sep 2006 19:41:33 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35481) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 14 Sep 2006 19:41:41 +0900 Message-Id: <6.0.0.20.2.20060914180527.083a2b20@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 14 Sep 2006 18:06:40 +0900 To: John Cowan , Randy Presuhn From: Martin Duerst Subject: Re: [Ltru] script tag for IPA In-Reply-To: <20060913181709.GQ10145@ccil.org> References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <20060913181709.GQ10145@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 03:17 06/09/14, John Cowan wrote: >There's only one relevant power that be, and that's (qua ISO 19542 >Registrar, not qua LSTR), and he's already rejected it. Good luck. The way I read ISO 19542, these decisions are made by (qualified) majority, not as implied above by a single person. Did I get something wrong? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 06:41:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNofA-0008FG-JH; Thu, 14 Sep 2006 06:41:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNofA-0008FB-7A for ltru@ietf.org; Thu, 14 Sep 2006 06:41:44 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNof8-0006V9-HQ for ltru@ietf.org; Thu, 14 Sep 2006 06:41:44 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8EAfU4x021050 for ; Thu, 14 Sep 2006 19:41:31 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 0420_9520165e_43dd_11db_8d23_0014221fa3c9; Thu, 14 Sep 2006 19:41:30 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35481) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 14 Sep 2006 19:41:38 +0900 Message-Id: <6.0.0.20.2.20060914173036.08322b60@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 14 Sep 2006 18:04:36 +0900 To: Peter Constable , From: Martin Duerst Subject: RE: [Ltru] script tag for IPA In-Reply-To: References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <4508C6EC.90305@sil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 12:25 06/09/14, Peter Constable wrote: >Content-Class: urn:content-classes:message >Content-Type: text/plain; charset="utf-8" > >From: Martin Hosken [mailto:martin_hosken@sil.org] > >> I'm not asking for Americanist to be considered its own script, I'm not >> asking for Pinyin to be its own script. So what is it about the IPA that >> makes me think of it as a separate script? >> >> 1. It is a worldwide standard that dominates its field and is >> immediately recognisable as such by anyone who can read it > >IMO a 15924 ID for Latin-based phonetic transcription would be appropriate. As a technical contributor, I disagree. If we have a script code for Latin-based transcriptions, then we will get a script code for Greek-based transcriptions, a script code for Cyrillic-based transciptions, and so on. Not very orthogonal. >But IMO it would not be appropriate to assign 15924 ID specific to some >systems of Latin-based phonetic transcription but not others. Latin-based >phonetic transcriptions should have one consistent mechanism of support in >IETF language tags. In my view, it would not be appropriate to assign any script codes to transciptions per se at all. But it would be appripriate to assign script codes to things that can be recognized as scripts, independent of whether they are used for transcriptions or not. In that sense, I see a clear difference e.g. between Wade-Giles and IPA. The clear goal of Wade-Giles is to write Chinese with Latin letters. Tagging it as Latn is very clearly appropriate. That it is a particular transcription, or in other words a particular orthography of Chinese when written in Latin, is secondary. We would like to figure out how to tag this secondary aspect, but we shouldn't confuse that with the primary aspect of using the Latin script. The clear goal of using IPA is *not* to use the Latin script, but to create a notation that is phonetically/phonemically unambiguous. That a lot of characters in IPA are taken from Latin, and some from Greek, is by convenience only. This is similar to Cyrillic (borrowing from Greek), or Cherokee. >My vote is to add a script variant ID "Lphn" or "Latp" to 15924 and then >register variant subtags denoting specific systems of phonetic >transcription each listing "Lphn" (or "Latp") as a prefix. Thus, we'd have >tags along the lines of "en-Lphn-intlphon", "chr-Lphn-amerphon", >"bad-Lphn-dokephon". This allows > >- matching content in some language whether using practical orthography or >phonetic transcription >- matching content in some language in phonetic transcription of any kind >- matching content in some language in some specific system of phonetic >transcription I don't want to say they are not. But while I think Michael is arguing too much from a font designer viewpoint (hey, IPA doesn't need a new font, just a few additional characters, and everything pretty much looks like standard Latin, while e.g. Fraktur looks way different), your argument above comes too much from a linguistic viewpoint. In many cases, I think transcriptions can already be identified by using a script other than the suppress-script (well, assuming we got these more complete :-(. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 07:07:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNp3s-0008Mp-L4; Thu, 14 Sep 2006 07:07:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNp3s-0008Mk-0S for ltru@ietf.org; Thu, 14 Sep 2006 07:07:16 -0400 Received: from mail17.svc.cra.dublin.eircom.net ([159.134.118.216]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GNp3q-00032l-N5 for ltru@ietf.org; Thu, 14 Sep 2006 07:07:15 -0400 Received: (qmail 88569 messnum 5072752 invoked from network[194.125.174.99/ts09-099.dublin.indigo.ie]); 14 Sep 2006 11:07:12 -0000 Received: from ts09-099.dublin.indigo.ie (HELO ?194.125.174.99?) (194.125.174.99) by mail17.svc.cra.dublin.eircom.net (qp 88569) with SMTP; 14 Sep 2006 11:07:12 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <20060914004742.GR10145@ccil.org> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <23BDD878-B405-42A4-9083-EAC998AE2256@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] script tag for IPA Date: Thu, 14 Sep 2006 12:05:11 +0000 To: ltru@ietf.org X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org So I believe, also. BTW, so many msgs are pouring through this list =20 at the moment that I also believe nobody could read all and still do =20 a decent day's work elsewhere, so this comment of mine is offered on =20 the basis that, although I have not read all of that barrage of msgs, =20= my gut professional feeling is that a tag for IPA would be a Good =20 Thing For All. As recently as 3 days ago, I was asked to supply Irish texts written =20 in IPA for a rather exciting, cutting-edge, project - while I could =20 supply some, there was no pointer I could supply for a live Net =20 search for more. mg On 14 Sep 2006, at 05:00, scr=EDobh Jukka K. Korpela: > ... > > The fact that some IPA letters have been coded in Unicode as =20 > identical to some Latin letters was just a practical choice and =20 > does not change the identity of the script - any more than the =20 > identity of the Cyrillic script would have been changed if Cyrillic =20= > "A" had been encoded as the same as Latin "A", etc. On 14 Sep 2006, at 08:44, scr=EDobh Martin Duerst: > As a technical contributor, I think that the Greek monotonic/=20 > polytonic distinction does not merit a script distinction, but that =20= > IPA can > easily be handled as a script. Good arguments for handling IPA > that way have been brought up by many people, I don't want to > repeat them. - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 07:44:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNpdX-0003zs-A7; Thu, 14 Sep 2006 07:44:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNpdV-0003zL-LN; Thu, 14 Sep 2006 07:44:05 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNpdT-0002P8-Aq; Thu, 14 Sep 2006 07:44:05 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004672078.msg; Thu, 14 Sep 2006 12:45:33 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 14 Sep 2006 12:44:07 +0100 From: "Debbie Garside" To: , Subject: RE: [Ltru] script tag for IPA Date: Thu, 14 Sep 2006 12:43:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcbX7jZPc8FjPk4OSLivqfvFfgCmHQABLC4A In-Reply-To: <23BDD878-B405-42A4-9083-EAC998AE2256@egt.ie> Message-ID: X-Spam-Processed: mx1.nexbyte.net, Thu, 14 Sep 2006 12:45:33 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDAV-Processed: mx1.nexbyte.net, Thu, 14 Sep 2006 12:45:33 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1=20 Debbie Garside > -----Original Message----- > From: Marion Gunn [mailto:mgunn@egt.ie]=20 > Sent: 14 September 2006 13:05 > To: ltru@ietf.org > Subject: Re: [Ltru] script tag for IPA >=20 > So I believe, also. BTW, so many msgs are pouring through=20 > this list at the moment that I also believe nobody could read=20 > all and still do a decent day's work elsewhere, so this=20 > comment of mine is offered on the basis that, although I have=20 > not read all of that barrage of msgs, my gut professional=20 > feeling is that a tag for IPA would be a Good Thing For All. >=20 > As recently as 3 days ago, I was asked to supply Irish texts=20 > written in IPA for a rather exciting, cutting-edge, project -=20 > while I could supply some, there was no pointer I could=20 > supply for a live Net search for more. > mg >=20 > On 14 Sep 2006, at 05:00, scr=EDobh Jukka K. Korpela: > > ... > > > > The fact that some IPA letters have been coded in Unicode=20 > as identical=20 > > to some Latin letters was just a practical choice and does=20 > not change=20 > > the identity of the script - any more than the identity of the=20 > > Cyrillic script would have been changed if Cyrillic "A" had been=20 > > encoded as the same as Latin "A", etc. >=20 > On 14 Sep 2006, at 08:44, scr=EDobh Martin Duerst: > > As a technical contributor, I think that the Greek monotonic/=20 > > polytonic distinction does not merit a script distinction, but that=20 > > IPA can easily be handled as a script. Good arguments for=20 > handling IPA=20 > > that way have been brought up by many people, I don't want=20 > to repeat=20 > > them. >=20 >=20 >=20 > - - > Marion Gunn * EGTeo (Estab.1991) > 27 P=E1irc an Fh=E9ithlinn, Baile an > Bh=F3thair, Co. =C1tha Cliath, =C9ire. > * mgunn@egt.ie * eamonn@egt.ie * >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 >=20 >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 07:46:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNpfZ-0004qg-KQ; Thu, 14 Sep 2006 07:46:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNpfY-0004oK-DJ for ltru@ietf.org; Thu, 14 Sep 2006 07:46:12 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNpfX-0002zZ-3X for ltru@ietf.org; Thu, 14 Sep 2006 07:46:12 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 6F1A626C17C; Thu, 14 Sep 2006 13:46:04 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 9F2AA26C191; Thu, 14 Sep 2006 13:46:03 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 9C04C58ECFE; Thu, 14 Sep 2006 13:46:03 +0200 (CEST) Date: Thu, 14 Sep 2006 13:46:03 +0200 From: Stephane Bortzmeyer To: John Cowan Message-ID: <20060914114603.GA11890@nic.fr> References: <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <4508C6EC.90305@sil.org> <4508CD1A.9050405@sil.org> <4508D30B.6030605@sil.org> <20060914042200.GT10145@ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060914042200.GT10145@ccil.org> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org Subject: [Ltru] Parsabiliy of tags (Was: script tag for IPA X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Thu, Sep 14, 2006 at 12:22:00AM -0400, John Cowan wrote a message of 29 lines which said: > This is already so. You can identify the subtags in a RFC 4646 tag > (excepting the few grandfathered ones) by a combination of subtag > length and the binary features +/-initial and +/-digits. Yes (but see later for a counter-example), but may be he wanted something that could be parsed by a simple engine, such as a regexp engine, without requiring a full parser? > For example, a 4-character subtag that is -initial and -digits is a > script; I do not think so, it depends on the context. In fr-x-abcd, 'abcd' is not a script. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 09:31:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNrJi-0000eP-HH; Thu, 14 Sep 2006 09:31:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNrJh-0000eK-NV for ltru@ietf.org; Thu, 14 Sep 2006 09:31:45 -0400 Received: from mta1.adelphia.net ([68.168.78.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNrJf-00089D-FU for ltru@ietf.org; Thu, 14 Sep 2006 09:31:45 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060914132626.CERD10083.mta9.adelphia.net@DGBP7M81>; Thu, 14 Sep 2006 09:26:26 -0400 Message-ID: <005201c6d801$5f7703c0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> <4506D714.4020705@yahoo-inc.com> <004301c6d6e1$72276d50$6401a8c0@DGBP7M81> <450826A0.2000206@yahoo-inc.com> Subject: Re: [Ltru] Can't add a Preferred-Value to a redundant tag Date: Thu, 14 Sep 2006 06:26:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > John points out that these tags have meanings defined by the 3066 > registration process, which is true. I don't have a problem with > deprecating the tags and it is probably best to include said > deprecation in the registry so that users will migrate to the new > tags. However... it *does* mean that we'll be breaking our own > precedent and (potentially) breaking someone's tags. The only action I can see that would break anything would be to redefine the registered meaning of "sgn-US" away from ASL and back to its generative meaning. And because you pointed out the clause about "broadening the meaning" of Registry entries, I'm not even sure that is at issue. We should be able to use the mechanisms we designed (in this case, deprecation and Preferred-Value) to solve the problems we face. This thread sounds as though someone else made the rules, and we are walking around with a screwdriver trying to figure out how to work around them. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 09:38:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNrQ0-0002m4-48; Thu, 14 Sep 2006 09:38:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNrPy-0002lq-P3 for ltru@ietf.org; Thu, 14 Sep 2006 09:38:14 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNrPx-0000BL-GC for ltru@ietf.org; Thu, 14 Sep 2006 09:38:14 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060914133808.TFBH29000.mta13.adelphia.net@DGBP7M81>; Thu, 14 Sep 2006 09:38:08 -0400 Message-ID: <005601c6d803$01e627c0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> <4506D714.4020705@yahoo-inc.com> <004301c6d6e1$72276d50$6401a8c0@DGBP7M81> <450826A0.2000206@yahoo-inc.com> <30b660a20609130901q18d1e97eu2370953c30d34062@mail.gmail.com> Subject: Re: [Ltru] Can't add a Preferred-Value to a redundant tag Date: Thu, 14 Sep 2006 06:38:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > sgn-US should simply mean "sign language as used in the US", which is > a widening of ASL. To perform that action, actually just dropping from > the registry would work. Every tag that was well-formed and valid > beforehand is also afterwards; and the semantic is broadened. I'd have > to read the rules again to see if that is permitted, however. It's only a question of *which* rule we want to relax: the one in Section 3.3 about not removing entries from the set of grandfathered and redundant tags, or the one in Section 3.1 about not adding a Preferred-Value to an existing entry that is not "grandfathered" or "region". What caused all this trouble was the practice of registering tags under RFC 3066 that were syntactically valid under RFC 3066, but carried a different meaning, and adding a clause to RFC 3066 that sanctioned this practice on the basis of "register[ing] information with the IANA about a tag defined by this document." We now have a set of "redundant" tags that are NOT truly redundant: they do NOT mean the same thing as a whole as by analyzing the pieces separately. This makes them fundamentally different from truly "redundant" tags such as "yi-latn" and "es-419". -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 09:54:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNrfc-00013N-M1; Thu, 14 Sep 2006 09:54:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNrfc-00013I-7o for ltru@ietf.org; Thu, 14 Sep 2006 09:54:24 -0400 Received: from mta1.adelphia.net ([68.168.78.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNrfa-0001Ha-W5 for ltru@ietf.org; Thu, 14 Sep 2006 09:54:24 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060914135028.EHWM28624.mta11.adelphia.net@DGBP7M81> for ; Thu, 14 Sep 2006 09:50:28 -0400 Message-ID: <006001c6d804$bb837060$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 14 Sep 2006 06:50:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> UTF-8 is far superior to markup, in my (biased, Unicadette) opinion, >> since it makes the file plain text in a well-known, well-declared, >> highly-desirable encoding. > > Yes. Not the maximal Latin-1 compatibility IFF you're willing to > spend up to 7 octets. But apparently the optimal encoding for maximal > ASCII compatibility. Actually up to 8 octets for the NCR format: [ & # x 2 0 1 9 ; ] I don't think it's been established that Latin-1 compatibility is a goal for an IANA registry. >> perhaps we should leave well enough alone. > > Yes, for other reasons like not annoying folks who implemented 4646 > validators (probably there are many more than only Doug, Stephane, and > you). I hope my earlier message made it clear that I do not mind redesigning my software for a different format, if the different format is judged better in some way. Old-timers may remember that the Registry was once planned to be bar-delimited, one line per entry, and I had to change my software when we moved to record-jar. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 10:09:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNruX-00086l-Pa; Thu, 14 Sep 2006 10:09:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNruX-00081L-12; Thu, 14 Sep 2006 10:09:49 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNruV-0002iV-Je; Thu, 14 Sep 2006 10:09:49 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004673859.msg; Thu, 14 Sep 2006 15:11:26 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 14 Sep 2006 15:09:58 +0100 From: "Debbie Garside" To: , "'LTRU Working Group'" Subject: RE: [Ltru] Re: Registry Format (was UTF-8) Date: Thu, 14 Sep 2006 15:09:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcbYBWuzvQqOWNlEScS0RtDkXgQILgAAHQkg In-Reply-To: <006001c6d804$bb837060$6401a8c0@DGBP7M81> Message-ID: <3F8B0FE9D86E40178302D77C1CD8B8D3.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Thu, 14 Sep 2006 15:11:26 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDAV-Processed: mx1.nexbyte.net, Thu, 14 Sep 2006 15:11:28 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi I apologise if you have already discussed this; I'm playing catchup after a Name Server error destroyed my email. >From the a non-technical aspect, I think the record jar format of the registry sucks. Can anyone see a situation where users will want to import the data into proprietary software - such as an Access database? For my own purposes, I would like to and the present format is not at all human/user friendly. A nice tab or comma delimited format would suit me. Or maybe I have missed a way to import the data (I tried many moons ago). Best regards Debbie Garside > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: 14 September 2006 14:50 > To: LTRU Working Group > Subject: [Ltru] Re: UTF-8 > > Frank Ellermann wrote: > > >> UTF-8 is far superior to markup, in my (biased, > Unicadette) opinion, > >> since it makes the file plain text in a well-known, well-declared, > >> highly-desirable encoding. > > > > Yes. Not the maximal Latin-1 compatibility IFF you're willing to > > spend up to 7 octets. But apparently the optimal encoding > for maximal > > ASCII compatibility. > > Actually up to 8 octets for the NCR format: [ & # x 2 0 1 9 ; ] > > I don't think it's been established that Latin-1 > compatibility is a goal for an IANA registry. > > >> perhaps we should leave well enough alone. > > > > Yes, for other reasons like not annoying folks who implemented 4646 > > validators (probably there are many more than only Doug, > Stephane, and > > you). > > I hope my earlier message made it clear that I do not mind > redesigning my software for a different format, if the > different format is judged better in some way. Old-timers > may remember that the Registry was once planned to be > bar-delimited, one line per entry, and I had to change my > software when we moved to record-jar. > > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > RFC 4645 * UTN #14 > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 10:28:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNsCx-0005zd-M7; Thu, 14 Sep 2006 10:28:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNsCw-0005xH-9u for ltru@ietf.org; Thu, 14 Sep 2006 10:28:50 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNsCt-0005Zj-TJ for ltru@ietf.org; Thu, 14 Sep 2006 10:28:50 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 710ED26C131; Thu, 14 Sep 2006 16:28:47 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 2C4A726C134; Thu, 14 Sep 2006 16:28:46 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 289AB58EBBE; Thu, 14 Sep 2006 16:28:46 +0200 (CEST) Date: Thu, 14 Sep 2006 16:28:46 +0200 From: Stephane Bortzmeyer To: Debbie Garside Message-ID: <20060914142846.GA11555@nic.fr> References: <006001c6d804$bb837060$6401a8c0@DGBP7M81> <3F8B0FE9D86E40178302D77C1CD8B8D3.MAI@home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F8B0FE9D86E40178302D77C1CD8B8D3.MAI@home> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'LTRU Working Group' Subject: [Ltru] Re: Registry Format (was UTF-8) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Thu, Sep 14, 2006 at 03:09:37PM +0100, Debbie Garside wrote a message of 80 lines which said: > From the a non-technical aspect, >From a technical aspect, remember that there are many possible formats for structured data and there is little chance of a consensus, even a rough one, on the "best" format. That's why, although I personnaly prefer XML, I have sympathy for the people who say "Do not touch it, do not reopen the discussion". > Can anyone see a situation where users will want to import the data > into proprietary software - such as an Access database? Sure, see later for a possible solution. > A nice tab or comma delimited format would suit me. CSV and similar formats have two big problems, for the *authoritative* copy of the registry: 1) They cannot handle structure of more than one level (not a problem for the language tag registry) 2) And, more important, they are not self-documented. When you find a JSON, XML or record-jar file, even if you have never seen these formats, you can reverse-engineer them and the field names are present. With CSV, you are lost. > Or maybe I have missed a way to import the data (I tried many moons > ago). Since there will be no consensus and because there are many use-cases such as "Import to Access" or "Process with awk", I suggest the following: 1) Let the reference format be record-jar, in the name of stability, 2) Create somewhere a Web site with translation tools *and the results* of these translations. That way, we will still have one authoritative form but people looking for such or such formats will be happy. I do not know if IANA (which seems quite busy) can handle this but we, as a community, certainly can. I presume we will not lack volunteers to produce recordjar2anything converters in Awk, Visual Basic, Haskell or Perl ? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 10:34:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNsIn-0001JT-7y; Thu, 14 Sep 2006 10:34:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNsIm-0001JO-Mk for ltru@ietf.org; Thu, 14 Sep 2006 10:34:52 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNsIl-00079m-D9 for ltru@ietf.org; Thu, 14 Sep 2006 10:34:52 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004674132.msg for ; Thu, 14 Sep 2006 15:36:30 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 14 Sep 2006 15:35:02 +0100 From: "Debbie Garside" To: Date: Thu, 14 Sep 2006 15:34:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcbYCkEXYLDe6LW0SBGHcT3OfHKh4gAAG2UQ In-Reply-To: <20060914142846.GA11555@nic.fr> Message-ID: <71B0DC4C653B441ABEE78F5E4C4A8BF8.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Thu, 14 Sep 2006 15:36:30 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Thu, 14 Sep 2006 15:36:32 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: 'LTRU Working Group' Subject: [Ltru] RE: Registry Format (was UTF-8) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Good answer Stephane! Let's hope someone creates those conversion tools. Best regards Debbie > -----Original Message----- > From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] > Sent: 14 September 2006 15:29 > To: Debbie Garside > Cc: 'LTRU Working Group' > Subject: Re: Registry Format (was UTF-8) > > On Thu, Sep 14, 2006 at 03:09:37PM +0100, Debbie Garside > wrote a message of 80 lines which said: > > > From the a non-technical aspect, > > From a technical aspect, remember that there are many > possible formats for structured data and there is little > chance of a consensus, even a rough one, on the "best" > format. That's why, although I personnaly prefer XML, I have > sympathy for the people who say "Do not touch it, do not > reopen the discussion". > > > Can anyone see a situation where users will want to import the data > > into proprietary software - such as an Access database? > > Sure, see later for a possible solution. > > > A nice tab or comma delimited format would suit me. > > CSV and similar formats have two big problems, for the > *authoritative* copy of the registry: > > 1) They cannot handle structure of more than one level (not a > problem for the language tag registry) > > 2) And, more important, they are not self-documented. When > you find a JSON, XML or record-jar file, even if you have > never seen these formats, you can reverse-engineer them and > the field names are present. With CSV, you are lost. > > > Or maybe I have missed a way to import the data (I tried many moons > > ago). > > Since there will be no consensus and because there are many > use-cases such as "Import to Access" or "Process with awk", I > suggest the > following: > > 1) Let the reference format be record-jar, in the name of stability, > > 2) Create somewhere a Web site with translation tools *and the > results* of these translations. That way, we will still have > one authoritative form but people looking for such or such > formats will be happy. > > I do not know if IANA (which seems quite busy) can handle > this but we, as a community, certainly can. I presume we will > not lack volunteers to produce recordjar2anything converters > in Awk, Visual Basic, Haskell or Perl ? > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 10:40:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNsO0-00042A-1C; Thu, 14 Sep 2006 10:40:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNsNz-000425-ET for ltru@ietf.org; Thu, 14 Sep 2006 10:40:15 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNsNy-00080Z-7S for ltru@ietf.org; Thu, 14 Sep 2006 10:40:15 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GNsNx-0003y1-OW; Thu, 14 Sep 2006 10:40:13 -0400 Date: Thu, 14 Sep 2006 10:40:13 -0400 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: Registry Format (was UTF-8) Message-ID: <20060914144013.GA337@ccil.org> References: <006001c6d804$bb837060$6401a8c0@DGBP7M81> <3F8B0FE9D86E40178302D77C1CD8B8D3.MAI@home> <20060914142846.GA11555@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060914142846.GA11555@nic.fr> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer scripsit: > > A nice tab or comma delimited format would suit me. > > CSV and similar formats have two big problems, for the *authoritative* > copy of the registry: > > 1) They cannot handle structure of more than one level (not a problem > for the language tag registry) Actually, we do have such structure, though not explicitly. Certain line types such as "Prefix" can be repeated, implying a two level structure Record >> Prefixes >> Prefix. > 2) And, more important, they are not self-documented. When you find a > JSON, XML or record-jar file, even if you have never seen these > formats, you can reverse-engineer them and the field names are > present. With CSV, you are lost. 3) Newly proposed records are passed around in email through most of their lifetimes: from proposer to list to LSR to IANA. Passing single very long lines through email is not a very reliable process. Furthermore, people often want to put commas into description/comment fields, requiring extra messy conventions using quotes or backslashes. Tabs are worse yet, since they are very easily transformed into spaces by mistake. Record-jar involves a small block of lines none of which has to be very long, thanks to the wrapping convention. (I might have proposed JSON if I'd known about it at the time.) -- Do what you will, John Cowan this Life's a Fiction cowan@ccil.org And is made up of http://www.ccil.org/~cowan Contradiction. --William Blake _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 10:42:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNsQS-0005Od-To; Thu, 14 Sep 2006 10:42:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNsQR-0005N3-Ue for ltru@ietf.org; Thu, 14 Sep 2006 10:42:47 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNsQQ-0008Nj-ON for ltru@ietf.org; Thu, 14 Sep 2006 10:42:47 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GNsQQ-00044p-De; Thu, 14 Sep 2006 10:42:46 -0400 Date: Thu, 14 Sep 2006 10:42:46 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: UTF-8 Message-ID: <20060914144246.GB337@ccil.org> References: <006001c6d804$bb837060$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006001c6d804$bb837060$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > Actually up to 8 octets for the NCR format: [ & # x 2 0 1 9 ; ] Actually up to 11: [ & # x 1 0 F F F F ; ], although in practice nothing more than 10 will ever be required. -- John Cowan cowan@ccil.org http://ccil.org/~cowan In computer science, we stand on each other's feet. --Brian K. Reid _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 10:43:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNsQl-0005kG-98; Thu, 14 Sep 2006 10:43:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNsQj-0005k6-BL for ltru@ietf.org; Thu, 14 Sep 2006 10:43:05 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNsQi-0008Si-2V for ltru@ietf.org; Thu, 14 Sep 2006 10:43:05 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 99AE126C134; Thu, 14 Sep 2006 16:43:03 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 9D36726C131; Thu, 14 Sep 2006 16:43:02 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 8F8FD58EBBE; Thu, 14 Sep 2006 16:43:02 +0200 (CEST) Date: Thu, 14 Sep 2006 16:43:02 +0200 From: Stephane Bortzmeyer To: Debbie Garside Message-ID: <20060914144302.GA14645@nic.fr> References: <20060914142846.GA11555@nic.fr> <71B0DC4C653B441ABEE78F5E4C4A8BF8.MAI@home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71B0DC4C653B441ABEE78F5E4C4A8BF8.MAI@home> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 'LTRU Working Group' Subject: [Ltru] Re: Registry Format (was UTF-8) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Thu, Sep 14, 2006 at 03:34:42PM +0100, Debbie Garside wrote a message of 71 lines which said: > Let's hope someone creates those conversion tools. My vision was more "community-oriented" (aka "Do It Yourself and Then Share"): a volunteer sets up and runs the Web site (AFNIC, my employer, certainly can host it) and then various volunteers submit tools and translations of the registry (not all tools will run on the platform used for the Web site, so not all translations will be produced by the Web site administrator). Of course, this will be a best-effort-no-warranty project, the authoritative registry being at IANA only. "Better to light a candle, than to complain about darkness" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 10:53:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNsao-0001IR-7w; Thu, 14 Sep 2006 10:53:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNsam-0001IH-Dp for ltru@ietf.org; Thu, 14 Sep 2006 10:53:28 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNsal-0002T9-5E for ltru@ietf.org; Thu, 14 Sep 2006 10:53:28 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004674518.msg for ; Thu, 14 Sep 2006 15:55:07 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 14 Sep 2006 15:53:40 +0100 From: "Debbie Garside" To: Date: Thu, 14 Sep 2006 15:53:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcbYDDsjY8RXlCFxQ/6Bm/eCedqk/wAAGOdw In-Reply-To: <20060914144302.GA14645@nic.fr> Message-ID: X-Spam-Processed: mx1.nexbyte.net, Thu, 14 Sep 2006 15:55:07 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Thu, 14 Sep 2006 15:55:08 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: 'LTRU Working Group' Subject: [Ltru] RE: Registry Format (was UTF-8) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane wrote: > My vision was more "community-oriented" (aka "Do It Yourself and Then > Share"): a volunteer sets up and runs the Web site (AFNIC, my > employer, certainly can host it) and then various volunteers > submit tools and translations of the registry (not all tools > will run on the platform used for the Web site, so not all > translations will be produced by the Web site administrator). I think that is an excellent idea with one exception, the site should host the translation/conversion tools and a link to the IANA Registry; that way a translation would always be up-to-date and there would be no registry conflicts. The tool could then be used when new Registry items are inserted or the user can make a decision to update "by hand" (although this option is inadvisable IMHO as it introduces human error). > Of course, this will be a best-effort-no-warranty project, > the authoritative registry being at IANA only. This would not be an issue if the "alternative" registry is not hosted. > "Better to light a candle, than to complain about darkness" We have the candle, just need a lighter! ;-) Debbie > > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 10:55:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNsd2-0001cD-63; Thu, 14 Sep 2006 10:55:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNsd0-0001c7-VL for ltru@ietf.org; Thu, 14 Sep 2006 10:55:46 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNscy-0002mH-NE for ltru@ietf.org; Thu, 14 Sep 2006 10:55:46 -0400 Received: from [10.72.72.6] (snvvpn1-10-72-72-c6.corp.yahoo.com [10.72.72.6]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8EEtg8C033928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Sep 2006 07:55:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=2e2Vc4sBwgn+3AjJE34fOS6MJ9gNECjPDtomQXd0AwiPe66d6jVU9CIDUJsfJY6w Message-ID: <45096D6C.3080702@yahoo-inc.com> Date: Thu, 14 Sep 2006 07:55:41 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Preferred-Value fun... References: <450842EC.3030007@yahoo-inc.com> <6.0.0.20.2.20060914180918.0838aec0@localhost> In-Reply-To: <6.0.0.20.2.20060914180918.0838aec0@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > > Does this change the meaning, or just make sure normative stuff > is defined in a single place? > It changes the meaning: Preferred-Value could then be registered for any record type, not just grandfathered and region. Formerly, this sentence prohibited registrations for the other types. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 11:38:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtIe-0004sm-3j; Thu, 14 Sep 2006 11:38:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtIc-0004sZ-Kt for ltru@ietf.org; Thu, 14 Sep 2006 11:38:46 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNtIa-0004w7-6W for ltru@ietf.org; Thu, 14 Sep 2006 11:38:46 -0400 Received: from [10.72.72.6] (snvvpn1-10-72-72-c6.corp.yahoo.com [10.72.72.6]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8EFcUWv030241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Sep 2006 08:38:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=mYTuEN+3x2HUe/VsSjBDgnywCseVKiKv5mHKVjkOgPZRYoImbYcyvQGcmvaSF/Qn Message-ID: <45097776.4090800@yahoo-inc.com> Date: Thu, 14 Sep 2006 08:38:30 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Can't add a Preferred-Value to a redundant tag References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> <4506D714.4020705@yahoo-inc.com> <004301c6d6e1$72276d50$6401a8c0@DGBP7M81> <450826A0.2000206@yahoo-inc.com> <30b660a20609130901q18d1e97eu2370953c30d34062@mail.gmail.com> <005601c6d803$01e627c0$6401a8c0@DGBP7M81> In-Reply-To: <005601c6d803$01e627c0$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > >> sgn-US should simply mean "sign language as used in the US", which is >> a widening of ASL. To perform that action, actually just dropping from >> the registry would work. Every tag that was well-formed and valid >> beforehand is also afterwards; and the semantic is broadened. I'd have >> to read the rules again to see if that is permitted, however. > > It's only a question of *which* rule we want to relax: the one in > Section 3.3 about not removing entries from the set of grandfathered and > redundant tags, Absolutely no way we should relax this rule. It makes a mockery of even having redundant tags. GF and redundant are supposed to be a complete set of the registered values from 3066... so that people can see exactly what happened to the tags. If we want to deprecate a tag, let's deprecate it. But hiding it is bad. or the one in Section 3.1 about not adding a > Preferred-Value to an existing entry that is not "grandfathered" or > "region". Currently, there is no way for us to deprecate language, extlang, script, or variant subtags, as well as redundant tags. The question we have to ask is whether we did this intelligently. Our thinking, expressed in the introduction to Section 3.4 (Stability), is "once canonical, always canonical for that meaning" and we had language subtags in particular in mind. Regions (countries, if we mean ISO 3166) do actually change over time, so included preferred-value registration there to accommodate it. But... RFC 4646 contains Section 3.4, item 14, which suggests that we artificially created a contradiction in the rules: -- 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. -- By removing the prohibition in Section 3.1, we reduce the number of rules overall and put the rules in one place. Preferred-Values can be added to any record, which reduces our need to review and oversee ISO's decisions to cases in which they recycle codes. > > What caused all this trouble was the practice of registering tags under > RFC 3066 that were syntactically valid under RFC 3066, but carried a > different meaning, and adding a clause to RFC 3066 that sanctioned this > practice on the basis of "register[ing] information with the IANA about > a tag defined by this document." We now have a set of "redundant" tags > that are NOT truly redundant: they do NOT mean the same thing as a whole > as by analyzing the pieces separately. This makes them fundamentally > different from truly "redundant" tags such as "yi-latn" and "es-419". Nothing says this in RFC 4646. If we intend to persist the registered meaning, we really should say so (and back out those records to grandfathered). But ultimately, I think the best course of action is: 1. Allow the registered meaning to remain, keeping the description (even though it could be broadened). Consider it historical. 2. Deprecate the redundant tag and provide the Preferred-Value (tell people what to do). 3. Relax in the knowledge that these tags are rare in practice and that we haven't hurt anyone (or anyone's content) in the process. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 11:40:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtJp-000570-An; Thu, 14 Sep 2006 11:40:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtJo-00056u-CG for ltru@ietf.org; Thu, 14 Sep 2006 11:40:00 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNtJl-0005JR-Lt for ltru@ietf.org; Thu, 14 Sep 2006 11:40:00 -0400 Received: by nf-out-0910.google.com with SMTP id n15so2209404nfc for ; Thu, 14 Sep 2006 08:39:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=b+JN3cIntYxzWij9zKZdrOBsTsxKBqB28ggeNPR5hQBqyMPJGI4+7S5FjmyiCcavpMgIt9oELn2mqfro9OVUxl1ie0dXNZZO+8YHNfz6RKfuqJoV+xUM9Yn0h0IaQqX8wanmvKJIHyWEEtaqva9pGV5P60G3zPcCEoZSly8meUQ= Received: by 10.49.91.6 with SMTP id t6mr12246093nfl; Thu, 14 Sep 2006 08:39:56 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Thu, 14 Sep 2006 08:39:55 -0700 (PDT) Message-ID: <30b660a20609140839l4698d6c5lb7f8cdad1e47c9cc@mail.gmail.com> Date: Thu, 14 Sep 2006 09:39:55 -0600 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] script tag for IPA In-Reply-To: <4508DE16.3080607@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <450812FA.3040906@sil.org> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <4508C6EC.90305@sil.org> <4508CD1A.9050405@sil.org> <4508DE16.3080607@yahoo-inc.com> X-Google-Sender-Auth: 7ffccb3c2be89c3c X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org We currently use a variant in CLDR for polytonic. But it doesn't work very well -- the orthography really should be before the country so that you get fallback working properly. (Cf long discussion in archive about use cases, such as fallback when mixing content from multiple sources.) Unfortunately, as we've seen, the script JAC hasn't been willing to add this, even though they have similar types of variation with Hant/s and Latn/f. So in CLDR what we are planning to do is to use a private-use script code for it. el-Qaap el-Qaap- The same probably holds true of IPA: the orthography is fundamentally much more important than the variation by country. Mark BTW, I really wish that Addison and I had been aware of the unresponsiveness of the script JAC when we first decided that we didn't need to have a mechanism for the registration of script codes! On 9/13/06, Addison Phillips wrote: > Peter Constable wrote: > > > > So, if we determine that the best solution to transcriptions > > and transliterations involves use of variant subtags that > > are constrained to a script but not a language, then we > > simply need to figure out what revisions to the doc > > should be made to achieve that. > > ::shudder:: I think that's a perfectly awful idea for how to handle > transcription/transliteration. I think extensions are entirely the best > way to handle this very specialized kind of language identification. > > However, only a very tiny modification would be necessary for what you > desire. Currently we use Basic Language Ranges for Prefix. Changing to > Extended Language Range would do what you want: > > Type: variant > Subtag: polyton > Prefix: *-Grek > Comments: This variant can also be applied to languages > with a Suppress-Script of 'Grek' > > > If we relax the prefix check on variants, this works functionally too. > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 11:46:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtQY-000897-Sj; Thu, 14 Sep 2006 11:46:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtQY-00088k-1b for ltru@ietf.org; Thu, 14 Sep 2006 11:46:58 -0400 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNtQW-0007O2-LA for ltru@ietf.org; Thu, 14 Sep 2006 11:46:58 -0400 Received: by nf-out-0910.google.com with SMTP id n15so2211596nfc for ; Thu, 14 Sep 2006 08:46:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ROwcuneBUUF1dxhb1kYSiAqt9g4AeROx2se5R3ehgfEGybKxT+lquy2795MlmdGLJ7rUjs3PKjTGIEnwp8AtdcMl4DrmpwwvmNz/eQD5PyMVZ6Xz7W3w1QVakF7M9LzQkUeN84oszENvivsoKVtAfkQQM/RWmwjo7l0rYFA+PRk= Received: by 10.49.10.3 with SMTP id n3mr12250392nfi; Thu, 14 Sep 2006 08:46:55 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Thu, 14 Sep 2006 08:46:55 -0700 (PDT) Message-ID: <30b660a20609140846i59c8885fg61aba180255a010@mail.gmail.com> Date: Thu, 14 Sep 2006 09:46:55 -0600 From: "Mark Davis" To: "Stephane Bortzmeyer" Subject: Re: [Ltru] Re: Registry Format (was UTF-8) In-Reply-To: <20060914142846.GA11555@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <006001c6d804$bb837060$6401a8c0@DGBP7M81> <3F8B0FE9D86E40178302D77C1CD8B8D3.MAI@home> <20060914142846.GA11555@nic.fr> X-Google-Sender-Auth: e4061fc56ce21021 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I agree; that's what we do for CLDR, for example. For example, for French there is an XML file at: http://unicode.org/cldr/data/common/main/fr.xml Then there are translations (actually multiple ones, with different slices of the data) at http://unicode.org/cldr/comparison_charts.html, such as: http://www.unicode.org/cldr/data/charts/summary/fr.html?hide Mark On 9/14/06, Stephane Bortzmeyer wrote: > On Thu, Sep 14, 2006 at 03:09:37PM +0100, > Debbie Garside wrote > a message of 80 lines which said: > > > From the a non-technical aspect, > > >From a technical aspect, remember that there are many possible formats > for structured data and there is little chance of a consensus, even a > rough one, on the "best" format. That's why, although I personnaly > prefer XML, I have sympathy for the people who say "Do not touch it, > do not reopen the discussion". > > > Can anyone see a situation where users will want to import the data > > into proprietary software - such as an Access database? > > Sure, see later for a possible solution. > > > A nice tab or comma delimited format would suit me. > > CSV and similar formats have two big problems, for the *authoritative* > copy of the registry: > > 1) They cannot handle structure of more than one level (not a problem > for the language tag registry) > > 2) And, more important, they are not self-documented. When you find a > JSON, XML or record-jar file, even if you have never seen these > formats, you can reverse-engineer them and the field names are > present. With CSV, you are lost. > > > Or maybe I have missed a way to import the data (I tried many moons > > ago). > > Since there will be no consensus and because there are many use-cases > such as "Import to Access" or "Process with awk", I suggest the > following: > > 1) Let the reference format be record-jar, in the name of stability, > > 2) Create somewhere a Web site with translation tools *and the > results* of these translations. That way, we will still have one > authoritative form but people looking for such or such formats will be > happy. > > I do not know if IANA (which seems quite busy) can handle this but we, > as a community, certainly can. I presume we will not lack volunteers > to produce recordjar2anything converters in Awk, Visual Basic, Haskell > or Perl ? > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 11:49:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtSb-0000RG-UQ; Thu, 14 Sep 2006 11:49:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtSb-0000RA-2V for ltru@ietf.org; Thu, 14 Sep 2006 11:49:05 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNtSZ-0000BB-MH for ltru@ietf.org; Thu, 14 Sep 2006 11:49:05 -0400 Received: by nf-out-0910.google.com with SMTP id n15so2212242nfc for ; Thu, 14 Sep 2006 08:49:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=NYkuMqJSNSOtWROBKuj/X4v18R9rAPqsdvTPQWelPnaANLxnDEwrgFtj8YcLVB1uf2KljT21BZZgWS7qeJzogZETFmvxM4HO0b6STZ/hs4j382zQ5anMFR5jToSzdnc/aEVCprDgW6Vtkywr6uo02ph/3qPPi0/80LXP1T2MA44= Received: by 10.49.8.10 with SMTP id l10mr12252825nfi; Thu, 14 Sep 2006 08:49:02 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Thu, 14 Sep 2006 08:49:01 -0700 (PDT) Message-ID: <30b660a20609140849h3d1ea8fyb7ded48753c02d3e@mail.gmail.com> Date: Thu, 14 Sep 2006 09:49:01 -0600 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Can't add a Preferred-Value to a redundant tag In-Reply-To: <45097776.4090800@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> <4506D714.4020705@yahoo-inc.com> <004301c6d6e1$72276d50$6401a8c0@DGBP7M81> <450826A0.2000206@yahoo-inc.com> <30b660a20609130901q18d1e97eu2370953c30d34062@mail.gmail.com> <005601c6d803$01e627c0$6401a8c0@DGBP7M81> <45097776.4090800@yahoo-inc.com> X-Google-Sender-Auth: fdc9145504f851eb X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Very sensible; I agree. Mark On 9/14/06, Addison Phillips wrote: > > > Doug Ewell wrote: > > > >> sgn-US should simply mean "sign language as used in the US", which is > >> a widening of ASL. To perform that action, actually just dropping from > >> the registry would work. Every tag that was well-formed and valid > >> beforehand is also afterwards; and the semantic is broadened. I'd have > >> to read the rules again to see if that is permitted, however. > > > > It's only a question of *which* rule we want to relax: the one in > > Section 3.3 about not removing entries from the set of grandfathered and > > redundant tags, > > Absolutely no way we should relax this rule. It makes a mockery of even > having redundant tags. GF and redundant are supposed to be a complete > set of the registered values from 3066... so that people can see exactly > what happened to the tags. If we want to deprecate a tag, let's > deprecate it. But hiding it is bad. > > or the one in Section 3.1 about not adding a > > Preferred-Value to an existing entry that is not "grandfathered" or > > "region". > > Currently, there is no way for us to deprecate language, extlang, > script, or variant subtags, as well as redundant tags. The question we > have to ask is whether we did this intelligently. Our thinking, > expressed in the introduction to Section 3.4 (Stability), is "once > canonical, always canonical for that meaning" and we had language > subtags in particular in mind. Regions (countries, if we mean ISO 3166) > do actually change over time, so included preferred-value registration > there to accommodate it. > > But... RFC 4646 contains Section 3.4, item 14, which suggests that we > artificially created a contradiction in the rules: > > -- > 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. > -- > > By removing the prohibition in Section 3.1, we reduce the number of > rules overall and put the rules in one place. Preferred-Values can be > added to any record, which reduces our need to review and oversee ISO's > decisions to cases in which they recycle codes. > > > > > What caused all this trouble was the practice of registering tags under > > RFC 3066 that were syntactically valid under RFC 3066, but carried a > > different meaning, and adding a clause to RFC 3066 that sanctioned this > > practice on the basis of "register[ing] information with the IANA about > > a tag defined by this document." We now have a set of "redundant" tags > > that are NOT truly redundant: they do NOT mean the same thing as a whole > > as by analyzing the pieces separately. This makes them fundamentally > > different from truly "redundant" tags such as "yi-latn" and "es-419". > > Nothing says this in RFC 4646. If we intend to persist the registered > meaning, we really should say so (and back out those records to > grandfathered). But ultimately, I think the best course of action is: > > 1. Allow the registered meaning to remain, keeping the description (even > though it could be broadened). Consider it historical. > > 2. Deprecate the redundant tag and provide the Preferred-Value (tell > people what to do). > > 3. Relax in the knowledge that these tags are rare in practice and that > we haven't hurt anyone (or anyone's content) in the process. > > Addison > > > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 11:54:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtXk-0004Dt-PA; Thu, 14 Sep 2006 11:54:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtXj-0004Do-E1 for ltru@ietf.org; Thu, 14 Sep 2006 11:54:23 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNtXi-0003Rd-2l for ltru@ietf.org; Thu, 14 Sep 2006 11:54:23 -0400 Received: from [10.72.72.6] (snvvpn1-10-72-72-c6.corp.yahoo.com [10.72.72.6]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8EFnASM030671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Sep 2006 08:49:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=b1xxB5z/tX+QO8HrkDn/y1LQ0vxyxtejHhle87pukq9R4e9j9uQWHBw76NoKklCd Message-ID: <450979F6.6050900@yahoo-inc.com> Date: Thu, 14 Sep 2006 08:49:10 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Can't add a Preferred-Value to a redundant tag References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> <4506D714.4020705@yahoo-inc.com> <004301c6d6e1$72276d50$6401a8c0@DGBP7M81> <450826A0.2000206@yahoo-inc.com> <005201c6d801$5f7703c0$6401a8c0@DGBP7M81> In-Reply-To: <005201c6d801$5f7703c0$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > We should be able to use the mechanisms we designed (in this case, > deprecation and Preferred-Value) to solve the problems we face. This > thread sounds as though someone else made the rules, and we are walking > around with a screwdriver trying to figure out how to work around them. > (laughing) No, it is just that we probably know the rules better than others and can use them to achieve a useful end. In my opinion, like some of the other registrations pre-4646, the sgn-* registrations are ill-considered junk. If we had "i-asl" we wouldn't be having this conversation: we'd have a grandfathered tag and we'd deprecate the heck out of it. But instead we have these "well-formed-but-not-meaning-what-they-say" tags...... So deprecate them, but allow the registered meaning to persist for those that pay attention to such things. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 12:20:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtx1-0002IT-Lp; Thu, 14 Sep 2006 12:20:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtwz-0002CK-Ua for ltru@lists.ietf.org; Thu, 14 Sep 2006 12:20:29 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNtwy-00044T-Cc for ltru@lists.ietf.org; Thu, 14 Sep 2006 12:20:29 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GNtwY-0003bw-A3 for ltru@lists.ietf.org; Thu, 14 Sep 2006 18:20:02 +0200 Received: from du-001-021.access.de.clara.net ([212.82.227.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Sep 2006 18:20:02 +0200 Received: from nobody by du-001-021.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Sep 2006 18:20:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 14 Sep 2006 18:13:24 +0200 Organization: Lines: 16 Message-ID: <45097FA4.3D92@xyzzy.claranet.de> References: <006001c6d804$bb837060$6401a8c0@DGBP7M81> <20060914144246.GB337@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-021.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > up to 11: [ & # x 1 0 F F F F ; ], although in practice > nothing more than 10 will ever be required. My "7" was for a Latin-1 friendly UTF-4, not escape sequences: Hex. 86 91 90 9F 9F 9F 9F (lead byte + 6 hex. digits), in that form a legacy text viewer or editor could display 191 visible Latin-1 characters as is, instead of "only" 95 ASCII for UTF-8. Of course we can't use this for the registry, and we also won't try BOCU-1. But maybe IANA should offer a gzip-ped version. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 12:21:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNty7-0003WS-VM; Thu, 14 Sep 2006 12:21:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNty7-0003WN-HJ for ltru@ietf.org; Thu, 14 Sep 2006 12:21:39 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNty6-0004Wk-9Q for ltru@ietf.org; Thu, 14 Sep 2006 12:21:39 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GNty5-0008CT-S2; Thu, 14 Sep 2006 12:21:37 -0400 Date: Thu, 14 Sep 2006 12:21:37 -0400 To: Mark Davis Subject: Re: [Ltru] script tag for IPA Message-ID: <20060914162137.GB20105@ccil.org> References: <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <4508C6EC.90305@sil.org> <4508CD1A.9050405@sil.org> <4508DE16.3080607@yahoo-inc.com> <30b660a20609140839l4698d6c5lb7f8cdad1e47c9cc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20609140839l4698d6c5lb7f8cdad1e47c9cc@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > We currently use a variant in CLDR for polytonic. But it doesn't work > very well -- the orthography really should be before the country so > that you get fallback working properly. (Cf long discussion in archive > about use cases, such as fallback when mixing content from multiple > sources.) Can you explain this more clearly? The difference between polytoniko and monotoniko orthographies *for the same variant of Greek* seems to me very small. To learn to read polytoniko, you learn that the accent has three different shapes, all of which mean the same thing, and that words beginning with vowel letters are preceded with either a left-comma or a right-comma, both of which mean nothing. Yannis Haralambous neatly classifies Greek into six major types: * ancient, epigraphical orthography (no accents, breathings, or lower case) * ancient, conventional orthography (three accents, two breathings, case) * katharevousa (same) * dimotiki in katharevousa context (same, spelling not standardized) * polytoniko dimotiki (same, sometimes acute for grave) * monotoniko dimotiki (one accent, no breathings) -- No, John. I want formats that are actually John Cowan useful, rather than over-featured megaliths that http://www.ccil.org/~cowan address all questions by piling on ridiculous cowan@ccil.org internal links in forms which are hideously over-complex. --Simon St. Laurent on xml-dev _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 12:24:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNu1I-000489-Li; Thu, 14 Sep 2006 12:24:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNu1H-00047p-AN for ltru@ietf.org; Thu, 14 Sep 2006 12:24:55 -0400 Received: from mail12.svc.cra.dublin.eircom.net ([159.134.118.28]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GNu1G-00052u-19 for ltru@ietf.org; Thu, 14 Sep 2006 12:24:55 -0400 Received: (qmail 64930 messnum 5763982 invoked from network[194.125.174.71/ts09-071.dublin.indigo.ie]); 14 Sep 2006 16:24:52 -0000 Received: from ts09-071.dublin.indigo.ie (HELO ?194.125.174.71?) (194.125.174.71) by mail12.svc.cra.dublin.eircom.net (qp 64930) with SMTP; 14 Sep 2006 16:24:52 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <30b660a20609140839l4698d6c5lb7f8cdad1e47c9cc@mail.gmail.com> References: <450812FA.3040906@sil.org> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <4508C6EC.90305@sil.org> <4508CD1A.9050405@sil.org> <4508DE16.3080607@yahoo-inc.com> <30b660a20609140839l4698d6c5lb7f8cdad1e47c9cc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <97B238A6-585D-4B71-9CF7-460E7F4D9235@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] script tag for IPA Date: Thu, 14 Sep 2006 17:22:52 +0000 To: ltru@ietf.org X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I think you have made a good argument for introducing such mechanism =20 ASAP. mg On 14 Sep 2006, at 15:39, scr=EDobh Mark Davis: > We currently use a variant in CLDR for polytonic. But it doesn't work > very well -- the orthography really should be before the country so > that you get fallback working properly. (Cf long discussion in archive > about use cases, such as fallback when mixing content from multiple > sources.) > > Unfortunately, as we've seen, the script JAC hasn't been willing to > add this, even though they have similar types of variation with Hant/s > and Latn/f. So in CLDR what we are planning to do is to use a > private-use script code for it. > > el-Qaap > el-Qaap- > > The same probably holds true of IPA: the orthography is fundamentally > much more important than the variation by country. > > Mark > > BTW, I really wish that Addison and I had been aware of the > unresponsiveness of the script JAC when we first decided that we > didn't need to have a mechanism for the registration of script codes! - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 12:36:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNuCU-0001mG-Mk; Thu, 14 Sep 2006 12:36:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNuCS-0001lu-OP; Thu, 14 Sep 2006 12:36:28 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNuCR-0006xb-E6; Thu, 14 Sep 2006 12:36:28 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004675790.msg; Thu, 14 Sep 2006 17:38:05 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 14 Sep 2006 17:36:40 +0100 From: "Debbie Garside" To: , Subject: RE: [Ltru] script tag for IPA Date: Thu, 14 Sep 2006 17:36:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcbYGoUSL29L3fZIQ5+thpVnwh9fJQAAJ5GQ In-Reply-To: <97B238A6-585D-4B71-9CF7-460E7F4D9235@egt.ie> Message-ID: X-Spam-Processed: mx1.nexbyte.net, Thu, 14 Sep 2006 17:38:05 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDAV-Processed: mx1.nexbyte.net, Thu, 14 Sep 2006 17:38:08 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Marion wrote: > I think you have made a good argument for introducing such=20 > mechanism ASAP. I think Marion is right! But I am not sure now is the time to do it! The main focus of this draft is to include ISO 639-3. To detract too much = from that mission may be a mistake if we are to stay on target vis-=E0-vis deadlines. The question is, how long would it take to propose text and = deal with the ensuing debate? That said, ISO 639-3 is not yet published. =20 Best regards Debbie > -----Original Message----- > From: Marion Gunn [mailto:mgunn@egt.ie]=20 > Sent: 14 September 2006 18:23 > To: ltru@ietf.org > Subject: Re: [Ltru] script tag for IPA >=20 > mg > On 14 Sep 2006, at 15:39, scr=EDobh Mark Davis: >=20 > > We currently use a variant in CLDR for polytonic. But it=20 > doesn't work=20 > > very well -- the orthography really should be before the country so=20 > > that you get fallback working properly. (Cf long discussion=20 > in archive=20 > > about use cases, such as fallback when mixing content from multiple > > sources.) > > > > Unfortunately, as we've seen, the script JAC hasn't been willing to=20 > > add this, even though they have similar types of variation=20 > with Hant/s=20 > > and Latn/f. So in CLDR what we are planning to do is to use a=20 > > private-use script code for it. > > > > el-Qaap > > el-Qaap- > > > > The same probably holds true of IPA: the orthography is=20 > fundamentally=20 > > much more important than the variation by country. > > > > Mark > > > > BTW, I really wish that Addison and I had been aware of the=20 > > unresponsiveness of the script JAC when we first decided that we=20 > > didn't need to have a mechanism for the registration of=20 > script codes! >=20 > - - > Marion Gunn * EGTeo (Estab.1991) > 27 P=E1irc an Fh=E9ithlinn, Baile an > Bh=F3thair, Co. =C1tha Cliath, =C9ire. > * mgunn@egt.ie * eamonn@egt.ie * >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 >=20 >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 16:40:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNy0m-0007iv-Mv; Thu, 14 Sep 2006 16:40:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNy0m-0007iq-4E for ltru@ietf.org; Thu, 14 Sep 2006 16:40:40 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNy0k-0004I2-Q6 for ltru@ietf.org; Thu, 14 Sep 2006 16:40:40 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8EKePFd044167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Sep 2006 13:40:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=n1MalbMb28N4gyRT0I2ztwWQnX5in7b87s3Gn7W5iL4yR1y4sj6T7NhMwNkJNv2v Message-ID: <4509BE39.5080400@yahoo-inc.com> Date: Thu, 14 Sep 2006 13:40:25 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "'LTRU Working Group'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ltru] [OT] IE7 RC1... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I installed Internet Explorer 7 release candidate 1 on Monday. Why do you care? Well, you click on "Tools | Internet Options" and click the "languages" button. Click "Add" and feast your eyes on a lovely bunch of RFC 4646 language tags. Visible are tags with script subtags (quite a list of them), alpha3 language subtags, and one with a UN M.49 region (in the tag "en-029"). There is still a fairly short arbitrary limit on tag length (16 characters), but otherwise things look pretty cool. Interestingly, there are no tags for Simplified vs. Traditional Chinese (just regional variations). Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 16:52:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNyCD-0004Zr-V3; Thu, 14 Sep 2006 16:52:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNyCC-0004Zl-Oa for ltru@ietf.org; Thu, 14 Sep 2006 16:52:28 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNyCA-0005B0-G4 for ltru@ietf.org; Thu, 14 Sep 2006 16:52:28 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 66627240814; Thu, 14 Sep 2006 22:52:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id EBF051164E; Thu, 14 Sep 2006 22:49:36 +0200 (CEST) Date: Thu, 14 Sep 2006 22:49:36 +0200 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20060914204936.GA7960@sources.org> References: <789E617C880666438EDEE30C2A3E8D10EEF1@mailsrvnt05.enet.sharplabs.com> <002501c6d623$4cca8ce0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002501c6d623$4cca8ce0$6401a8c0@DGBP7M81> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: LTRU Working Group Subject: [Ltru] IANA and XML (Was: RFC 4645 on Initial Language Subtag Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Mon, Sep 11, 2006 at 09:23:59PM -0700, Doug Ewell wrote a message of 32 lines which said: > Has anyone had any thoughts about that? Any news about the supposed > plan to move all IANA registries to XML? Asked about that, Kim Davies (IANA), together with David Conrad (IANA director) told me that IANA intended to resume this project "in the next few weeks". So, if this is true (remember that IANA is often quite busy), this may be an opportunity. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 17:29:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNyll-0002RI-MC; Thu, 14 Sep 2006 17:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNylk-0002RB-I6 for ltru@ietf.org; Thu, 14 Sep 2006 17:29:12 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNylh-0001pw-7B for ltru@ietf.org; Thu, 14 Sep 2006 17:29:12 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.628.4; Thu, 14 Sep 2006 14:29:08 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Thu, 14 Sep 2006 14:28:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] script tag for IPA Date: Thu, 14 Sep 2006 14:28:18 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] script tag for IPA Thread-Index: AcbYGoUSL29L3fZIQ5+thpVnwh9fJQAAJ5GQAApcZ1A= From: Peter Constable To: X-OriginalArrivalTime: 14 Sep 2006 21:28:25.0745 (UTC) FILETIME=[B679D010:01C6D844] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I believe if you check our new charter, dealing with transcriptions and = transliterations is part of the work plan, as well as incorporation of = 639-3. Peter > -----Original Message----- > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Sent: Thursday, September 14, 2006 9:36 AM > To: ltru-bounces@ietf.org; ltru@ietf.org > Subject: RE: [Ltru] script tag for IPA >=20 > Marion wrote: >=20 > > I think you have made a good argument for introducing such > > mechanism ASAP. >=20 > I think Marion is right! But I am not sure now is the time to do it! = The > main focus of this draft is to include ISO 639-3. To detract too much > from > that mission may be a mistake if we are to stay on target vis-=E0-vis > deadlines. The question is, how long would it take to propose text = and > deal > with the ensuing debate? That said, ISO 639-3 is not yet published. >=20 > Best regards >=20 > Debbie >=20 > > -----Original Message----- > > From: Marion Gunn [mailto:mgunn@egt.ie] > > Sent: 14 September 2006 18:23 > > To: ltru@ietf.org > > Subject: Re: [Ltru] script tag for IPA > > > > mg > > On 14 Sep 2006, at 15:39, scr=EDobh Mark Davis: > > > > > We currently use a variant in CLDR for polytonic. But it > > doesn't work > > > very well -- the orthography really should be before the country = so > > > that you get fallback working properly. (Cf long discussion > > in archive > > > about use cases, such as fallback when mixing content from = multiple > > > sources.) > > > > > > Unfortunately, as we've seen, the script JAC hasn't been willing = to > > > add this, even though they have similar types of variation > > with Hant/s > > > and Latn/f. So in CLDR what we are planning to do is to use a > > > private-use script code for it. > > > > > > el-Qaap > > > el-Qaap- > > > > > > The same probably holds true of IPA: the orthography is > > fundamentally > > > much more important than the variation by country. > > > > > > Mark > > > > > > BTW, I really wish that Addison and I had been aware of the > > > unresponsiveness of the script JAC when we first decided that we > > > didn't need to have a mechanism for the registration of > > script codes! > > > > - - > > Marion Gunn * EGTeo (Estab.1991) > > 27 P=E1irc an Fh=E9ithlinn, Baile an > > Bh=F3thair, Co. =C1tha Cliath, =C9ire. > > * mgunn@egt.ie * eamonn@egt.ie * > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 17:49:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNz5i-0002Dn-FN; Thu, 14 Sep 2006 17:49:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNz5g-0002Dh-RF for ltru@lists.ietf.org; Thu, 14 Sep 2006 17:49:48 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNz5d-00069H-Eq for ltru@lists.ietf.org; Thu, 14 Sep 2006 17:49:48 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GNz5A-0000nm-SK for ltru@lists.ietf.org; Thu, 14 Sep 2006 23:49:16 +0200 Received: from pd9fbace3.dip0.t-ipconnect.de ([217.251.172.227]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Sep 2006 23:49:16 +0200 Received: from nobody by pd9fbace3.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Sep 2006 23:49:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 14 Sep 2006 23:48:34 +0200 Organization: Lines: 14 Message-ID: <4509CE32.22E8@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbace3.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Ltru] Re: script tag for IPA X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > dealing with transcriptions and transliterations is part of > the work plan So far I think that eliminating generic variants before they are abused to emulate extension registries could address this. The extension registry can define its own rules, e.g. say that tags with a t-whatever extension must always specify Latn (or maybe never, anything that makes sense depending on t-whatever) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 17:54:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNzAK-0005V1-My; Thu, 14 Sep 2006 17:54:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNzAK-0005RT-2J for ltru@ietf.org; Thu, 14 Sep 2006 17:54:36 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNzAI-0006Wt-N3 for ltru@ietf.org; Thu, 14 Sep 2006 17:54:36 -0400 Received: by nf-out-0910.google.com with SMTP id n15so2303140nfc for ; Thu, 14 Sep 2006 14:54:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=gEmiFG4ow25rbr7OtqJNscrxwq3ILzDKgTnqL7CjpzUFwNbCJOkSfRwSHdGJErnryglgXfT9yNTVtFb2iYZFAeLA7k9Y04pGsDAEQmn53lEZzEc8XbBrB6ARZAdwwV9YQ9s0QTdwOulglYgJWeS2wwCzC3s3brcj9u+ElUqx8jc= Received: by 10.49.8.1 with SMTP id l1mr12621879nfi; Thu, 14 Sep 2006 14:54:33 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Thu, 14 Sep 2006 14:54:33 -0700 (PDT) Message-ID: <30b660a20609141454m35ba8508n1021d5ba2437661a@mail.gmail.com> Date: Thu, 14 Sep 2006 14:54:33 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] script tag for IPA In-Reply-To: <20060914162137.GB20105@ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <4508C6EC.90305@sil.org> <4508CD1A.9050405@sil.org> <4508DE16.3080607@yahoo-inc.com> <30b660a20609140839l4698d6c5lb7f8cdad1e47c9cc@mail.gmail.com> <20060914162137.GB20105@ccil.org> X-Google-Sender-Auth: 16672fb8f28ec8aa X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Recognizability is not so much a problem as professional appearance is. Consider once again (this is in the archives) the fallback issue, the reason why script is higher than country. Consider the case where I am constructing a document (eg web page) from multiple sources. For source A, I have -- - for source B -- - What I get on the document if I ask for - or -- is a ransom-note-look, a mixture of orthographies. Even if the orthographies are legible, it is not a professional result. The reason for this is that the differences between Hant and Hans, between polytonic and monotonic, etc. are much larger than the differences between countries. And that is why part of the design of language tags is that they be "big endian". So as a practical matter, where the othographic distinction rises to the point where it is more important than the regional differences, you want it first. -- - for source B -- - What I get on the web page if I ask for - or -- is something that has a better appearance. This is the case for polytonic, and it even more clearly the case for IPA. The difference between IPA and standard orthography clearly completely swamps the difference between British and US spellings. Mark On 9/14/06, John Cowan wrote: > Mark Davis scripsit: > > > We currently use a variant in CLDR for polytonic. But it doesn't work > > very well -- the orthography really should be before the country so > > that you get fallback working properly. (Cf long discussion in archive > > about use cases, such as fallback when mixing content from multiple > > sources.) > > Can you explain this more clearly? The difference between polytoniko > and monotoniko orthographies *for the same variant of Greek* seems > to me very small. To learn to read polytoniko, you learn that the > accent has three different shapes, all of which mean the same thing, > and that words beginning with vowel letters are preceded with either > a left-comma or a right-comma, both of which mean nothing. > > Yannis Haralambous neatly classifies Greek into six major types: > > * ancient, epigraphical orthography (no accents, breathings, or lower case) > * ancient, conventional orthography (three accents, two breathings, case) > * katharevousa (same) > * dimotiki in katharevousa context (same, spelling not standardized) > * polytoniko dimotiki (same, sometimes acute for grave) > * monotoniko dimotiki (one accent, no breathings) > > -- > No, John. I want formats that are actually John Cowan > useful, rather than over-featured megaliths that http://www.ccil.org/~cowan > address all questions by piling on ridiculous cowan@ccil.org > internal links in forms which are hideously > over-complex. --Simon St. Laurent on xml-dev > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 22:00:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO2zo-0006aK-8H; Thu, 14 Sep 2006 22:00:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO2zm-0006VP-QE for ltru@ietf.org; Thu, 14 Sep 2006 21:59:58 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO1IV-0005O6-J7 for ltru@ietf.org; Thu, 14 Sep 2006 20:11:12 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8F0AwKc057732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Sep 2006 17:11:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=iDxalshUsbOI2RUZaxeK4ueUit9T0WtNZyc6n7QugK/e8Cqg0wbXVp3h20IVvSfw Message-ID: <4509EF92.5080008@yahoo-inc.com> Date: Thu, 14 Sep 2006 17:10:58 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] transcriptions and transliterations References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > I believe if you check our new charter, > dealing with transcriptions and transliterations > is part of the work plan, as well as incorporation > of 639-3. > It is mentioned as a use case (along with sign languages). I think there are several approaches we might take, but each has its disadvantages. Ducking the problem would probably work. I tend to prefer this option because I tend to think that most of these variations do not fit in with the traditional use of language tags or the requirements of most users of language tags. It is possible that there are things about a given piece of content that a language tag cannot completely identify and this may even be a good thing. My problem is that transcriptions and transliterations tend to be linked to specific languages/language pairs, scripts, or traditions. Usually, these processes are applied to a text to make it accessible to users of a different writing system or orthographic tradition--usually far removed from the traditional form of the source language. Such "wide gap" cases can often be identified well-enough with existing script codes or using other means. For example "en-Cyrl", "ru-Latn", and "zh-Latn" all convey the script and what was done to the text pretty well. Knowing the specific transcription scheme is valuable in some or even many cases, but unnecessary for most language tag uses. I also think there are cases where ISO 15924 should reconsider what defines a "script". I don't think Mark's Greek cases are really "transcriptions" or "transliterations". The Greek case, for example, is just a separate writing tradition within the Greek language. One can speak of transcribing a text between the two traditions, but that is not the same degree of transformation as, say, recording your Chinese document in Latin script. Thus, I think ISO 15924 should consider (since they have a vast codespace of over 450,000 codes) defining some codes---perhaps special purpose "profile" codes---to describe specialized uses of particular scripts. The Greek case, various Japanese codes, and Hant/Hans fit that model: there is still a high degree of correspondence between the distinct cases, but clearly a different usage of the "script" or combination of scripts is taking place. IPA might fit here too: it is used to write many languages and represents a very specialized use of (mostly) Latin script. So: I think that the WG should try to get ISO 15924 to consider the definition of scripts more carefully, while we should also suggest that specialists needing to identify the specifics of the transliteration/transcription process in a language tag work to develop an extension for that purpose. What I don't think we should do is make up something. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 22:38:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO3bE-0004hq-HI; Thu, 14 Sep 2006 22:38:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO3bC-0004hC-QD for ltru@ietf.org; Thu, 14 Sep 2006 22:38:38 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO3bB-0002c5-Hf for ltru@ietf.org; Thu, 14 Sep 2006 22:38:38 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060915023837.UFAI28624.mta11.adelphia.net@DGBP7M81>; Thu, 14 Sep 2006 22:38:37 -0400 Message-ID: <002d01c6d870$0bb62120$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> <4506D714.4020705@yahoo-inc.com> <004301c6d6e1$72276d50$6401a8c0@DGBP7M81> <450826A0.2000206@yahoo-inc.com> <30b660a20609130901q18d1e97eu2370953c30d34062@mail.gmail.com> <005601c6d803$01e627c0$6401a8c0@DGBP7M81> <45097776.4090800@yahoo-inc.com> Subject: Re: [Ltru] Can't add a Preferred-Value to a redundant tag Date: Thu, 14 Sep 2006 19:38:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >> It's only a question of *which* rule we want to relax: the one in >> Section 3.3 about not removing entries from the set of grandfathered >> and redundant tags, > > Absolutely no way we should relax this rule. It makes a mockery of > even having redundant tags. GF and redundant are supposed to be a > complete set of the registered values from 3066... so that people can > see exactly what happened to the tags. If we want to deprecate a tag, > let's deprecate it. But hiding it is bad. I agree 100%. I had to bring it up as "an" option, since Mark had suggested it, but it's not one I prefer. > But... RFC 4646 contains Section 3.4, item 14, which suggests that we > artificially created a contradiction in the rules: This actually doesn't surprise me, since these were among the most complex rules in one of the most bureaucratic parts of the document. > By removing the prohibition in Section 3.1, we reduce the number of > rules overall and put the rules in one place. Preferred-Values can be > added to any record, which reduces our need to review and oversee > ISO's decisions to cases in which they recycle codes. Sounds good, especially the part about putting the rules in one place. > Nothing says this in RFC 4646. If we intend to persist the registered > meaning, we really should say so (and back out those records to > grandfathered). Hold on. They are semantically grandfathered, but syntactically redundant. They consist wholly of subtags that could be combined to form a valid tag. That is central to the concept of "grandfathered" and we should not change this definition. > But ultimately, I think the best course of action is: > > 1. Allow the registered meaning to remain, keeping the description > (even though it could be broadened). Consider it historical. Figuratively, of course. There is no such formal category in the Registry (like "Deprecated") and I assume you are not proposing one. > 2. Deprecate the redundant tag and provide the Preferred-Value (tell > people what to do). > > 3. Relax in the knowledge that these tags are rare in practice and > that we haven't hurt anyone (or anyone's content) in the process. I agree with all of this. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 14 22:55:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO3rQ-0002Wx-8X; Thu, 14 Sep 2006 22:55:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO3rO-0002Ws-Py for ltru@ietf.org; Thu, 14 Sep 2006 22:55:22 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO3rL-0003lx-Vk for ltru@ietf.org; Thu, 14 Sep 2006 22:55:22 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8F2tIAL027548 for ; Fri, 15 Sep 2006 11:55:18 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 22e5_9ebd0658_4465_11db_9ed1_0014221f2a2d; Fri, 15 Sep 2006 11:55:17 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:53356) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 15 Sep 2006 11:55:25 +0900 Message-Id: <6.0.0.20.2.20060915102806.08383ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 15 Sep 2006 10:38:46 +0900 To: "Mark Davis" , "Addison Phillips" From: Martin Duerst Subject: Re: [Ltru] script tag for IPA In-Reply-To: <30b660a20609140839l4698d6c5lb7f8cdad1e47c9cc@mail.gmail.co m> References: <450812FA.3040906@sil.org> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> <20060913202947.GC22114@ccil.org> <4508C6EC.90305@sil.org> <4508CD1A.9050405@sil.org> <4508DE16.3080607@yahoo-inc.com> <30b660a20609140839l4698d6c5lb7f8cdad1e47c9cc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Mark, At 00:39 06/09/15, Mark Davis wrote: >We currently use a variant in CLDR for polytonic. But it doesn't work >very well -- the orthography really should be before the country so >that you get fallback working properly. (Cf long discussion in archive >about use cases, such as fallback when mixing content from multiple >sources.) > >Unfortunately, as we've seen, the script JAC hasn't been willing to >add this, even though they have similar types of variation with Hant/s >and Latn/f. So in CLDR what we are planning to do is to use a >private-use script code for it. This will be highly non-interoperable, I guess. I think we should be careful to distinguish two things: 1) Scripts 2) Orthographies I think you have given good arguments (in a separate mail) why major orthographic diffenences such as simplified/traditional for Chinese or monotonic/polytonic for Greek are in many cases more important than country differences. But there is a difference between orthography and script. It would be a bad idea if we ended up saying that anything that's arguably more important than a country difference is a script difference. What would look optimal to me would be to have variants after the script in certain circumstances, such as el-Grek-monotonic-gr and el-Grek-polytonic-gr. >BTW, I really wish that Addison and I had been aware of the >unresponsiveness of the script JAC when we first decided that we >didn't need to have a mechanism for the registration of script codes! You mean in RFC 4646? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 01:13:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO60N-0007Od-EH; Fri, 15 Sep 2006 01:12:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO60M-0007OY-6Q for ltru@ietf.org; Fri, 15 Sep 2006 01:12:46 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO60K-0000qC-Sh for ltru@ietf.org; Fri, 15 Sep 2006 01:12:46 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060915051243.MILC23328.mta13.adelphia.net@DGBP7M81> for ; Fri, 15 Sep 2006 01:12:43 -0400 Message-ID: <003b01c6d885$934747d0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 14 Sep 2006 22:12:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] Re: script tag for IPA X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I note that the LTRU 2.0 charter says to consider possibilities for tagging transliterations and transcriptions, specifically in the context of extlangs and variants (I would add "or extensions"). It does *not* say we should try to twist the arm of various ISO MA's and RA's to make their standards fit our needs. If IPA does not fit the ISO 15924 definition of "script," or if the Registrar and/or RA disagrees with adding it, then that is that and it is not our business to change that. We saw something similar in LTRU 1.0 with ISO 3166. If ISO 3166/MA does not find it within their policy to assign official country code elements for non-country entities, such as the European Union or OPEC or NATO or what have you, that is their call. We can and should ask them to take stability measures that will not adversely affect their ability to assign new code elements, but asking them to change the scope of the standard goes well beyond that. We can suggest, but I don't think we should flog. (Note that I completely avoided the question of whether IPA is a flavor of Latin or a separate script; this was wholly intentional.) -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 01:22:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6AC-00030p-KK; Fri, 15 Sep 2006 01:22:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6AB-0002yN-AT for ltru@ietf.org; Fri, 15 Sep 2006 01:22:55 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO6A9-0002tJ-2g for ltru@ietf.org; Fri, 15 Sep 2006 01:22:55 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060915052252.RIWB27224.mta10.adelphia.net@DGBP7M81> for ; Fri, 15 Sep 2006 01:22:52 -0400 Message-ID: <003f01c6d886$fdf90310$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 14 Sep 2006 22:22:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] Re: script tag for IPA X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > This is part of the general problem of transliteration/transcription, > which is not (yet) handled by the RFC 4646 framework. The best > permanent answer is probably to create a -t-xxxx standardized > extension to 4646, as provided for, and to create a registration > authority to register and maintain codes for different > transliterations. +1 with gusto. This is the best use case for extensions that I have seen yet. Most people agree that they are different in nature from either language, script, or the kind of "linguistic variety" usually associated with variants, and are too well-understood to be relegated to private-use. Remove-from-right fallback should not be the main determinant of which subtags carry which information. If that is so important, we should not have spent so much time developing a matching draft that offers better schemes. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 01:33:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6Ki-0007WR-7i; Fri, 15 Sep 2006 01:33:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6Kh-0007WM-8H for ltru@ietf.org; Fri, 15 Sep 2006 01:33:47 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO6Ke-0003tM-0Q for ltru@ietf.org; Fri, 15 Sep 2006 01:33:47 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060915053343.DCZN28624.mta11.adelphia.net@DGBP7M81> for ; Fri, 15 Sep 2006 01:33:43 -0400 Message-ID: <005101c6d888$81dc05f0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 14 Sep 2006 22:33:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Re: Preferred-Value fun... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > For fields of type 'language' and 'extlang', > 'Preferred-Value' contains the language production > (see ) that is preferred > when forming the language tag. This can be simply a > 'language' subtag, or it can be a 'language' subtag > followed by an extended language sequence. This isn't for the redundant "sgn-XX" tags. What was the intended use for this again? -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 01:49:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6aC-00051U-4i; Fri, 15 Sep 2006 01:49:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6aB-00051P-S0 for ltru@ietf.org; Fri, 15 Sep 2006 01:49:47 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO6aA-0005ch-MB for ltru@ietf.org; Fri, 15 Sep 2006 01:49:47 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GO6aA-0002yL-Av; Fri, 15 Sep 2006 01:49:46 -0400 Date: Fri, 15 Sep 2006 01:49:46 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Preferred-Value fun... Message-ID: <20060915054946.GB6907@ccil.org> References: <005101c6d888$81dc05f0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005101c6d888$81dc05f0$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > Addison Phillips wrote: > > > For fields of type 'language' and 'extlang', > > 'Preferred-Value' contains the language production > > (see ) that is preferred > > when forming the language tag. This can be simply a > > 'language' subtag, or it can be a 'language' subtag > > followed by an extended language sequence. > > This isn't for the redundant "sgn-XX" tags. What was the intended use > for this again? 639 going off the rails: we register the replacement tag with a Preferred-Value of the existing tag. -- There are three kinds of people in the world: John Cowan those who can count, cowan@ccil.org and those who can't. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 01:49:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6aI-00055D-7S; Fri, 15 Sep 2006 01:49:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6aH-000558-Pq for ltru@ietf.org; Fri, 15 Sep 2006 01:49:53 -0400 Received: from mta2.adelphia.net ([68.168.78.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO6aG-0005dC-Iu for ltru@ietf.org; Fri, 15 Sep 2006 01:49:53 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060915054521.WHAR10468.mta9.adelphia.net@DGBP7M81> for ; Fri, 15 Sep 2006 01:45:21 -0400 Message-ID: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 14 Sep 2006 22:45:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Re: script tag for IPA X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Hosken wrote: > My understanding of RFC 4646 is that extensions like intlphon need to > be registered *per language*. There seems to be no concept of script > extensions. So either we have to hide it behind a chr-Lphn-t-ipa-phn > (ipa phonemic) or do something else? But I may have misread the RFC. Extensions do not have to be language-specific AFAICT. This would be completely dependent on how the extension RFC is written. Unlike variants, this would work right out of the box, without any changes to the RFC 4646 wording. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 01:51:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6br-000609-Q6; Fri, 15 Sep 2006 01:51:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6bq-000604-V8 for ltru@ietf.org; Fri, 15 Sep 2006 01:51:30 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO6bp-0005xH-Nt for ltru@ietf.org; Fri, 15 Sep 2006 01:51:30 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060915055129.SMXL27224.mta10.adelphia.net@DGBP7M81> for ; Fri, 15 Sep 2006 01:51:29 -0400 Message-ID: <005d01c6d88a$fd378b00$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 14 Sep 2006 22:51:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Ltru] Re: script tag for IPA X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I think extensions are entirely the best way to handle this very > specialized kind of language identification. +1 > However, only a very tiny modification would be necessary for what you > desire. Currently we use Basic Language Ranges for Prefix. Changing to > Extended Language Range would do what you want: > > Type: variant > Subtag: polyton > Prefix: *-Grek > Comments: This variant can also be applied to languages > with a Suppress-Script of 'Grek' Big -1. Introducing this kind of wildcard syntax into the Registry would be a highly effective way of reducing the number of conformant implementations. > If we relax the prefix check on variants, this works functionally too. I think extensions are entirely the best way to handle this very specialized kind of language identification. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 01:54:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6eM-00075I-2q; Fri, 15 Sep 2006 01:54:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6eK-000758-DQ for ltru@ietf.org; Fri, 15 Sep 2006 01:54:04 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO6eI-0006hT-6c for ltru@ietf.org; Fri, 15 Sep 2006 01:54:04 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GO6eH-000338-Tb; Fri, 15 Sep 2006 01:54:01 -0400 Date: Fri, 15 Sep 2006 01:54:01 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: script tag for IPA Message-ID: <20060915055401.GC6907@ccil.org> References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > Martin Hosken wrote: > > >My understanding of RFC 4646 is that extensions like intlphon need to > >be registered *per language*. There seems to be no concept of script > >extensions. So either we have to hide it behind a chr-Lphn-t-ipa-phn > >(ipa phonemic) or do something else? But I may have misread the RFC. > > Extensions do not have to be language-specific AFAICT. I think Martin means variants rather than extensions. -- John Cowan http://ccil.org/~cowan cowan@ccil.org Mr. Henry James writes fiction as if it were a painful duty. --Oscar Wilde _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 02:00:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6kq-0001bK-1N; Fri, 15 Sep 2006 02:00:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6ko-0001aX-PD for ltru@ietf.org; Fri, 15 Sep 2006 02:00:46 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO6km-0008NT-F0 for ltru@ietf.org; Fri, 15 Sep 2006 02:00:46 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060915060043.OAYE23328.mta13.adelphia.net@DGBP7M81>; Fri, 15 Sep 2006 02:00:43 -0400 Message-ID: <006901c6d88c$47d3c600$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <005101c6d888$81dc05f0$6401a8c0@DGBP7M81> <20060915054946.GB6907@ccil.org> Subject: Re: [Ltru] Re: Preferred-Value fun... Date: Thu, 14 Sep 2006 23:00:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >>> For fields of type 'language' and 'extlang', >>> 'Preferred-Value' contains the language production >>> (see ) that is preferred >>> when forming the language tag. This can be simply a >>> 'language' subtag, or it can be a 'language' subtag >>> followed by an extended language sequence. >> >> This isn't for the redundant "sgn-XX" tags. What was the intended >> use for this again? > > 639 going off the rails: we register the replacement tag with a > Preferred-Value of the existing tag. You mean like "yue" being moved out of the "zh" ("zho") macrolanguage umbrella, and/or being added to 639-2? Type: language Subtag: yue Description: Chinese, Yue Added: xxxx-xx-xx Preferred-Value: zh-yue Deprecated: xxxx-xx-xx %% -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 02:09:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6tK-0004vd-Ao; Fri, 15 Sep 2006 02:09:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6tI-0004vY-QJ for ltru@ietf.org; Fri, 15 Sep 2006 02:09:32 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO6tH-0001Ov-Go for ltru@ietf.org; Fri, 15 Sep 2006 02:09:32 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060915060930.OHTL23328.mta13.adelphia.net@DGBP7M81> for ; Fri, 15 Sep 2006 02:09:30 -0400 Message-ID: <006d01c6d88d$82023950$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 14 Sep 2006 23:09:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ltru] Re: Registry Format (was UTF-8) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > (I might have proposed JSON if I'd known about it at the time.) I'll probably end up providing unofficial XML and JSON versions of the Registry. The multiple-value problem (for example, Description) is one reason we abandoned the bar-delimited format. We would have had to choose one ISO-provided description and ignore the rest: language | es | Spanish | 2005-10-16 | Latn | | or else use a subfield delimiter and pray it never appeared in real descriptions: language | es | Spanish; Castilian | 2005-10-16 | Latn | | -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 02:14:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6yA-0007AS-K9; Fri, 15 Sep 2006 02:14:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6y9-00079s-Fl for ltru@ietf.org; Fri, 15 Sep 2006 02:14:33 -0400 Received: from smtp1.wsfo.org ([208.145.81.52] helo=smtp2.wsfo.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO6y5-0002p6-Ra for ltru@ietf.org; Fri, 15 Sep 2006 02:14:33 -0400 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp2.wsfo.org (8.13.1/8.13.1) with ESMTP id k8F6EJp4025757 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Fri, 15 Sep 2006 02:14:19 -0400 X-Scanned-By: MIMEDefang 2.54 on 172.22.0.52 X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp X-Scanned-By: This message was scanned by MPP Free Edition (www.messagepartners.com)! Received: from [203.150.136.129] (account martin_hosken@sil.org HELO [192.168.1.6]) by mail.link77.net (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 122738080; Fri, 15 Sep 2006 02:14:18 -0400 Message-ID: <450A44B6.3060905@sil.org> Date: Fri, 15 Sep 2006 13:14:14 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Re: script tag for IPA References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> In-Reply-To: <20060915055401.GC6907@ccil.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Doug Ewell , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear John, >>> My understanding of RFC 4646 is that extensions like intlphon need to >>> be registered *per language*. There seems to be no concept of script >>> extensions. So either we have to hide it behind a chr-Lphn-t-ipa-phn >>> (ipa phonemic) or do something else? But I may have misread the RFC. >>> >> Extensions do not have to be language-specific AFAICT. >> > > I think Martin means variants rather than extensions. > Sorry. Indeed I should have written variants rather than extensions. As I see it we have a problem on our hands regarding scripts. I am not just talking here about transliteration schemes, I'm talking about scripts and script variants, including the Polytonic greek question, the myriad of Arabic and Burmese and who knows what else script variants that are out there. I think it is unreasonable to try to pressure ISO 15924 to become a standard aimed at supporting something it was designed to support. But further than that we do need to acknowledge that many of these things are script variants and not just new scripts (despite my feelings about IPA :)) Mark has shown the difficulty of using the existing variant scheme for scripts in that script variants, since they constitute writing systems, have a greater effect on a text than does regional variation and that because current variants are stored after the region identifier are considered of lower importance. I would like to offer a possible solution for people to consider/laugh at/whatever. I suggest that we introduce the concept of a script variant that modifies a script subtag, that is valid for all languages and is only scoped by the script it occurs following. The subtag shall be 4 characters long and start with an initial capital letter just like an existing script subtag. Given the space within ISO 15924 I'm sure we can come to some agreement over carving out a codespace for such variants. Failing that we could make the variant start and finish with a capital letter or use any capitalisation trick we feel like using to mark this thing. Since it is exactly 4 chars long it looks like a script tag to existing mechanisms (although if they are hyper strict they will get fed up) and would occur before the region subtag and after the script tag. They would be clearly identifiable since they are neither the right size for a region subtag or a variant subtag. The effect would be to add a mechanism of script variation that would take priority over regions, be clearly identifiable and would resolve many of the frustrations over ISO 15924. I hasten to add that I am *not* suggesting this as a solution to the transcription extensions issue, which I agree should be handled via an extension. I *am* suggesting it as a solution to the scripts question where a particular script variant may occur across many languages and is identifiably different in some key respect (here unspecified) to the script it is varying from. Thank you for your consideration. Yours, Martin Hosken _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 02:37:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO7Jy-0007SY-0O; Fri, 15 Sep 2006 02:37:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO7Jw-0007ST-T0 for ltru@ietf.org; Fri, 15 Sep 2006 02:37:04 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO7Jt-00010m-2g for ltru@ietf.org; Fri, 15 Sep 2006 02:37:04 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8F6asqx016063 for ; Fri, 15 Sep 2006 15:36:54 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 1c78_93994a42_4484_11db_828d_0014221fa3c9; Fri, 15 Sep 2006 15:36:53 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:46434) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 15 Sep 2006 15:37:01 +0900 Message-Id: <6.0.0.20.2.20060915151418.06670ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 15 Sep 2006 15:20:09 +0900 To: Addison Phillips , "'LTRU Working Group'" From: Martin Duerst Subject: Re: [Ltru] diffs, changes, etc. In-Reply-To: <4505AD19.9080809@yahoo-inc.com> References: <4505AD19.9080809@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 03:38 06/09/12, Addison Phillips wrote: >I just submitted draft-00 to the I-D editor. There is a 'changes from RFC 4646' section. Given material changes from RFC 4646 are supposed to be small, but potentially very relevant for implementing software, I think this section should be much more precise. >7. I cut down the acknowledgments list. I will add names as I incorporate textual suggestions. This is fine, but: 1) it should not say that RFC 4647 is a precursor of this document, and 2) it should not say that Michael was the Language Subtag Reviewer since RFC 1766, because there was no Language Subtag Reviewer at that time. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 02:37:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO7Kc-0007VZ-MH; Fri, 15 Sep 2006 02:37:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO7Kb-0007VU-HM for ltru@ietf.org; Fri, 15 Sep 2006 02:37:45 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO7Ka-00018K-8E for ltru@ietf.org; Fri, 15 Sep 2006 02:37:45 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060915063232.UCHE27224.mta10.adelphia.net@DGBP7M81>; Fri, 15 Sep 2006 02:32:32 -0400 Message-ID: <007501c6d890$b96ff410$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 14 Sep 2006 23:32:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Frank Ellermann Subject: [Ltru] [OT] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> up to 11: [ & # x 1 0 F F F F ; ], although in practice nothing more >> than 10 will ever be required. > > My "7" was for a Latin-1 friendly UTF-4, not escape sequences: > > Hex. 86 91 90 9F 9F 9F 9F (lead byte + 6 hex. digits), in that form a > legacy text viewer or editor could display 191 visible Latin-1 > characters as is, instead of "only" 95 ASCII for UTF-8. First, you said UTF-8, not this. Second, highly non-standard, but a fun thought experiment of the kind I used to indulge in. I'm not sure why you chose 0x86 as your sequence introducer (U+0086 START OF SELECTED AREA, or in Wnidows-1252, U+2020 DAGGER). If all C1 control bytes are available, you could make each sequence 1 byte shorter by marking the lead or trail byte specially: 81 90 9F 9F 9F 9F <- lead byte 8x, all others 9x 81 80 8F 8F 8F 9F <- trail byte 9x, all others 8x "Terminal jockeys" such as Frank da Cruz (inventor of the Kermit protocol) would argue that C1 controls are also part of "Latin-1" and hence this format is still not Latin-1-friendly (a complaint that also used to be brought against UTF-8). > Of course we can't use this for the registry, and we also won't try > BOCU-1. But maybe IANA should offer a gzip-ped version. BOCU-1 text tends to include a lot of bytes in the C1 range (0x80 through 0x9F) and might not travel through e-mail very well. And I still haven't received a clear answer about how patent-encumbered BOCU-1 might be. I like the gzip idea. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 04:13:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO8pQ-0007fe-VX; Fri, 15 Sep 2006 04:13:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO8pP-0007eP-6d for ltru@ietf.org; Fri, 15 Sep 2006 04:13:39 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO8pN-00055E-T9 for ltru@ietf.org; Fri, 15 Sep 2006 04:13:39 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 7E6F326C1C5; Fri, 15 Sep 2006 10:13:37 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 385E026C1D9; Fri, 15 Sep 2006 10:13:36 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 3499D58ED1C; Fri, 15 Sep 2006 10:13:36 +0200 (CEST) Date: Fri, 15 Sep 2006 10:13:36 +0200 From: Stephane Bortzmeyer To: Doug Ewell , John Cowan Message-ID: <20060915081336.GA28869@nic.fr> References: <006d01c6d88d$82023950$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006d01c6d88d$82023950$6401a8c0@DGBP7M81> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: LTRU Working Group Subject: [Ltru] Messages from John Cowan not distributed everywhere? (Was: Registry Format (was UTF-8) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Thu, Sep 14, 2006 at 11:09:29PM -0700, Doug Ewell wrote a message of 29 lines which said: > John Cowan wrote: > > >(I might have proposed JSON if I'd known about it at the time.) > > I'll probably end up providing unofficial XML and JSON versions of the > Registry. This is not the first time that I see a reply to John Cowan's messages but not the message itself. His message has been sent to the archives: http://www1.ietf.org/mail-archive/web/ltru/current/msg05512.html but not to my servers. I grepped the message ID (E1GNtIe-0004ss-Bs@megatron.ietf.org) in the logs of all our mail servers (in case it has been eaten by a too eager anti-spam system) but I've found nothing. Some messages from John Cowan do arrive to my mailbox, so the problem is mysterious. Does anyone have an idea? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 04:39:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO9Ej-0007Rd-95; Fri, 15 Sep 2006 04:39:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO9Ei-0007RF-GP for ltru@lists.ietf.org; Fri, 15 Sep 2006 04:39:48 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO9Ee-0007d4-UP for ltru@lists.ietf.org; Fri, 15 Sep 2006 04:39:48 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GO9EU-0000w0-Ev for ltru@lists.ietf.org; Fri, 15 Sep 2006 10:39:34 +0200 Received: from pd9fbad2d.dip0.t-ipconnect.de ([217.251.173.45]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Sep 2006 10:39:34 +0200 Received: from nobody by pd9fbad2d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Sep 2006 10:39:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 15 Sep 2006 10:26:09 +0200 Organization: Lines: 149 Message-ID: <450A63A1.3A81@xyzzy.claranet.de> References: <006001c6d804$bb837060$6401a8c0@DGBP7M81> <3F8B0FE9D86E40178302D77C1CD8B8D3.MAI@home> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------70443F234E95" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad2d.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Subject: [Ltru] Re: Registry Format X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org --------------70443F234E95 Debbie Garside wrote: > the present format is not at all human/user friendly. Matter of taste, I like it. > A nice tab or comma delimited format would suit me. I've no clue how you would handle multiple descriptions, comments, or prefixes in such formats, you'd need two separators, a field separator (tab or comma), and some secondary separator. And for that you would have to escape these two separators somehow if they appear as ordinary characters (e.g. a comma in a description). Just for fun I've created a gawk-script to convert the registry to XML - it still needs a DTD. Does that help you ? See below. Frank --------------70443F234E95 Content-Type: text/plain; charset=us-ascii; name="ltru2xml.awk" Content-Disposition: inline; filename="ltru2xml.awk" #! /usr/common/bin/gawk -f # # usage: ltru2xml.awk file > file.xml # #### remove leading and trailing spaces ########################### function STRIP( STR ) { sub( /^[\t ]+/, "", STR ) sub( /[\t ]+$/, "", STR ) return STR } #### error ######################################################## function FATAL( STR ) { print "error " NR ": " STR return 1 } #### save unfolded field body ##################################### function FIELD() { if ( NAME == "description" ) D[ ++DD ] = BODY else if ( NAME == "comments" ) C[ ++CC ] = BODY else if ( NAME == "prefix" ) P[ ++PP ] = BODY else if ( F[ NAME ] == "" ) F[ NAME ] = BODY else exit FATAL( NAME ": " BODY ) return } #### output collected record fields ############################### function READY() { T = F[ "type" ] if ( T == "" ) exit FATAL( "missing type" ) L = "<" T A = F[ "added" ] if ( A == "" ) exit FATAL( "missing date" ) L = L " date='" A "' " S = F[ "subtag" ] if ( S == "" ) S = F[ "tag" ] if ( S == "" ) exit FATAL( "missing tag" ) if ( F[ "tag" ] != "" && F[ "subtag" ] != "" ) exit FATAL( "conflicting subtag " S ) print L "tag='" S "'>" S = F[ "preferred-value" ] A = F[ "deprecated" ] if ( A != "" ) { L = " " else print L "tag='" S "' />" } else if ( S != "" ) exit FATAL( "missing deprecated" ) while ( PP ) print " " while ( CC ) { L = " " C[ CC-- ] print L " " } if ( DD == 0 ) exit FATAL( "missing description" ) while ( DD ) { L = " " D[ DD-- ] print L " " } S = F[ "suppress-script" ] if ( S != "" && T == "language" ) print " " else if ( S != "" ) exit FATAL( "unexpected Suppress-Script" S ) print "" return } #### init ######################################################### BEGIN { L = "" DOCT = "ltru" } #### record ####################################################### /^%%$/ { FIELD() if ( NN++ ) READY() else { L = "<" DOCT " date='" A = F[ "file-date" ] if ( A == "" ) exit FATAL( "missing File-Date" ) print L A "' />" } for ( NAME in F ) delete F[ NAME ] NAME = "" ; CC = 0 ; PP = 0 BODY = "" ; DD = 0 ; next } #### field ######################################################## /^[A-Za-z0-9]/ { FIELD() if ( ! match( $0, ":" )) exit FATAL( $0 ) NAME = tolower( substr( $0, 1, RSTART - 1 )) BODY = STRIP( substr( $0, RSTART + 1 )) next } #### LWSP ######################################################### /^ / { BODY = BODY " " STRIP( $0 ) next } #### toast ######################################################## { exit FATAL( $0 ) } ################################################################### END { if ( NN++ ) { FIELD() ; READY() } if ( --NN ) print "" print NN " records processed" > "/dev/tty" } --------------70443F234E95 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --------------70443F234E95-- From ltru-bounces@ietf.org Fri Sep 15 05:00:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO9Ys-0005Ta-PL; Fri, 15 Sep 2006 05:00:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO9Yr-0005RD-T4 for ltru@lists.ietf.org; Fri, 15 Sep 2006 05:00:37 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO9Yq-0000Ww-J6 for ltru@lists.ietf.org; Fri, 15 Sep 2006 05:00:37 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GO9Yc-0004nh-1m for ltru@lists.ietf.org; Fri, 15 Sep 2006 11:00:22 +0200 Received: from pd9fbad2d.dip0.t-ipconnect.de ([217.251.173.45]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Sep 2006 11:00:22 +0200 Received: from nobody by pd9fbad2d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Sep 2006 11:00:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 15 Sep 2006 10:59:41 +0200 Organization: Lines: 15 Message-ID: <450A6B7D.65C6@xyzzy.claranet.de> References: <006d01c6d88d$82023950$6401a8c0@DGBP7M81> <20060915081336.GA28869@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad2d.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Ltru] Re: Messages from John Cowan not distributed everywhere? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > I grepped the message ID (E1GNtIe-0004ss-Bs@megatron.ietf.org) [...] > Does anyone have an idea? That's the msg-id in Doug's references. Doug reads the list in digest format, it's not John's original msg-id. Here's his original article from GMaNe's POV: news://news.gmane.org/20060914144013.GA337@ccil.org http://article.gmane.org/gmane.ietf.ltru/5502/raw Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 05:12:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO9k8-00011L-Rc; Fri, 15 Sep 2006 05:12:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO9k7-00011G-V9 for ltru@lists.ietf.org; Fri, 15 Sep 2006 05:12:15 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO9k5-0001Iq-M5 for ltru@lists.ietf.org; Fri, 15 Sep 2006 05:12:15 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 250BD26C1DA; Fri, 15 Sep 2006 11:12:13 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 694E426C196; Fri, 15 Sep 2006 11:12:12 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 5CE2558ECFE; Fri, 15 Sep 2006 11:12:12 +0200 (CEST) Date: Fri, 15 Sep 2006 11:12:12 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20060915091212.GA6376@nic.fr> References: <006d01c6d88d$82023950$6401a8c0@DGBP7M81> <20060915081336.GA28869@nic.fr> <450A6B7D.65C6@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450A6B7D.65C6@xyzzy.claranet.de> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@lists.ietf.org Subject: [Ltru] Re: Messages from John Cowan not distributed everywhere? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, Sep 15, 2006 at 10:59:41AM +0200, Frank Ellermann wrote a message of 15 lines which said: > That's the msg-id in Doug's references. Doug reads the list in > digest format, it's not John's original msg-id. Here's his original > article from GMaNe's POV: Thanks but it is the same thing for 20060914144013.GA337@ccil.org, it was never presented to my mail servers :-( So it does not seem to be the fault of my anti-spam system. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 05:16:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO9oK-00024A-Vw; Fri, 15 Sep 2006 05:16:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO9oK-000245-0b for ltru@lists.ietf.org; Fri, 15 Sep 2006 05:16:36 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO9oI-0001yo-Nc for ltru@lists.ietf.org; Fri, 15 Sep 2006 05:16:35 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GO9o6-0007we-57 for ltru@lists.ietf.org; Fri, 15 Sep 2006 11:16:22 +0200 Received: from pd9fbad2d.dip0.t-ipconnect.de ([217.251.173.45]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Sep 2006 11:16:22 +0200 Received: from nobody by pd9fbad2d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Sep 2006 11:16:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 15 Sep 2006 11:14:18 +0200 Organization: Lines: 18 Message-ID: <450A6EEA.13A6@xyzzy.claranet.de> References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad2d.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] Re: script tag for IPA X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Hosken wrote: > a possible solution for people to consider/laugh at/whatever. Picking whatever: "Case insensitive" is a fundamental concept in 1766 / 3066 / 4646, and the default for anything you do in the IETF - the complete ABNF is per default "case insensitive" (nothing elaborated, only US-ASCII). Changing that is straight out. Better try a similar idea with an extension regitry, e.g. s-whatever for "script variants", or s-Latn-whatever for "Latn-variants" (etc.) The "whatever" part does not need its own registry, if anything folks like to use goes you can say so in the required "s-" RFC. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 05:35:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOA6e-0008L3-TY; Fri, 15 Sep 2006 05:35:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOA6d-0008Kn-2J for ltru@lists.ietf.org; Fri, 15 Sep 2006 05:35:31 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOA6b-0003s2-Pn for ltru@lists.ietf.org; Fri, 15 Sep 2006 05:35:31 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GOA6S-0003PY-Km for ltru@lists.ietf.org; Fri, 15 Sep 2006 11:35:20 +0200 Received: from pd9fbad2d.dip0.t-ipconnect.de ([217.251.173.45]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Sep 2006 11:35:20 +0200 Received: from nobody by pd9fbad2d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Sep 2006 11:35:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 15 Sep 2006 11:33:31 +0200 Organization: Lines: 22 Message-ID: <450A736B.4B84@xyzzy.claranet.de> References: <005101c6d888$81dc05f0$6401a8c0@DGBP7M81> <20060915054946.GB6907@ccil.org> <006901c6d88c$47d3c600$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad2d.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] Re: Preferred-Value fun... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Type: language > Subtag: yue > Description: Chinese, Yue > Added: xxxx-xx-xx > Preferred-Value: zh-yue > Deprecated: xxxx-xx-xx > %% Or vice versa: Type: extlang Subtag: bad Description: Bad Chinese Prefix: zh Added: xxxx-xx-xx Comment: Found to be no Chinese at all Preferred-Value: bad Deprecated: xxxx-xx-xx %% _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 05:52:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOAMa-0005GU-Px; Fri, 15 Sep 2006 05:52:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOAMZ-0005GP-He for ltru@lists.ietf.org; Fri, 15 Sep 2006 05:51:59 -0400 Received: from smtp1.wsfo.org ([208.145.81.52] helo=smtp2.wsfo.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOAMX-0006Fh-7Q for ltru@lists.ietf.org; Fri, 15 Sep 2006 05:51:59 -0400 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp2.wsfo.org (8.13.1/8.13.1) with ESMTP id k8F9puBp003119 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Fri, 15 Sep 2006 05:51:56 -0400 X-Scanned-By: MIMEDefang 2.54 on 172.22.0.52 X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp X-Scanned-By: This message was scanned by MPP Free Edition (www.messagepartners.com)! Received: from [203.150.136.129] (account martin_hosken@sil.org HELO [192.168.1.6]) by mail.link77.net (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 122754071; Fri, 15 Sep 2006 05:51:55 -0400 Message-ID: <450A77B8.5050603@sil.org> Date: Fri, 15 Sep 2006 16:51:52 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: script tag for IPA References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <450A6EEA.13A6@xyzzy.claranet.de> In-Reply-To: <450A6EEA.13A6@xyzzy.claranet.de> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear Frank, >> a possible solution for people to consider/laugh at/whatever. >> > > Picking whatever: "Case insensitive" is a fundamental concept > in 1766 / 3066 / 4646, and the default for anything you do in > the IETF - the complete ABNF is per default "case insensitive" > (nothing elaborated, only US-ASCII). > Thanks for that. > Changing that is straight out. Better try a similar idea with > an extension regitry, e.g. s-whatever for "script variants", or > s-Latn-whatever for "Latn-variants" (etc.) > No because the script variation needs to come before region in priority terms. In addition we need to indicate which extension marker marks a script extension and which a language extension. Yours, Martin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 06:12:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOAgC-0003Xb-Ar; Fri, 15 Sep 2006 06:12:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOAgA-0003XV-R5 for ltru@ietf.org; Fri, 15 Sep 2006 06:12:14 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOAg6-0000s0-V3 for ltru@ietf.org; Fri, 15 Sep 2006 06:12:14 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8FAC5BW028387 for ; Fri, 15 Sep 2006 19:12:05 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 1d53_a35fa796_44a2_11db_83c6_0014221fa3c9; Fri, 15 Sep 2006 19:12:04 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49631) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 15 Sep 2006 19:12:11 +0900 Message-Id: <6.0.0.20.2.20060915154910.06e040b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 15 Sep 2006 15:51:04 +0900 To: Martin Hosken , John Cowan From: Martin Duerst Subject: Re: [Ltru] Re: script tag for IPA In-Reply-To: <450A44B6.3060905@sil.org> References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Doug Ewell , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org The solution proposed by Martin Hosken seems to make quite a bit of sense to me. I only see two problems: - This would need a change to the RFC 4646 ABNF. This is serious. - Everything related to lanuguage tags is case-insensitive. The proposal below contains some case rules; these should (and can easily) be dropped. Regards, Martin. At 15:14 06/09/15, Martin Hosken wrote: >I would like to offer a possible solution for people to consider/laugh >at/whatever. > >I suggest that we introduce the concept of a script variant that >modifies a script subtag, that is valid for all languages and is only >scoped by the script it occurs following. The subtag shall be 4 >characters long and start with an initial capital letter just like an >existing script subtag. Given the space within ISO 15924 I'm sure we can >come to some agreement over carving out a codespace for such variants. >Failing that we could make the variant start and finish with a capital >letter or use any capitalisation trick we feel like using to mark this >thing. Since it is exactly 4 chars long it looks like a script tag to >existing mechanisms (although if they are hyper strict they will get fed >up) and would occur before the region subtag and after the script tag. >They would be clearly identifiable since they are neither the right size >for a region subtag or a variant subtag. > >The effect would be to add a mechanism of script variation that would >take priority over regions, be clearly identifiable and would resolve >many of the frustrations over ISO 15924. > >I hasten to add that I am *not* suggesting this as a solution to the >transcription extensions issue, which I agree should be handled via an >extension. I *am* suggesting it as a solution to the scripts question >where a particular script variant may occur across many languages and is >identifiably different in some key respect (here unspecified) to the >script it is varying from. > >Thank you for your consideration. > >Yours, >Martin Hosken > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 07:07:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOBXe-0005qN-FK; Fri, 15 Sep 2006 07:07:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOBXd-0005qI-B5 for ltru@lists.ietf.org; Fri, 15 Sep 2006 07:07:29 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOBXa-0001I6-Sg for ltru@lists.ietf.org; Fri, 15 Sep 2006 07:07:29 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GOBXP-0005po-NY for ltru@lists.ietf.org; Fri, 15 Sep 2006 13:07:15 +0200 Received: from pd9fbad2d.dip0.t-ipconnect.de ([217.251.173.45]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Sep 2006 13:07:15 +0200 Received: from nobody by pd9fbad2d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Sep 2006 13:07:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 15 Sep 2006 13:03:35 +0200 Organization: Lines: 64 Message-ID: <450A8887.EAB@xyzzy.claranet.de> References: <007501c6d890$b96ff410$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad2d.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Subject: [Ltru] Re: [OT] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > I'm not sure why you chose 0x86 as your sequence introducer Six is the number of trailing octets: 91909F9F9F9F (for John's example u+10FFFF). > you could make each sequence 1 byte shorter by marking the > lead or trail byte specially Yes, but then only 2 octets (80+81) would never occur (instead of 11), and lost 9x bytes won't cause an error. UTF-8 has now 13 "impossible" octets, and similar features. > "Terminal jockeys" such as Frank da Cruz (inventor of the > Kermit protocol) would argue that C1 controls are also part > of "Latin-1" and hence this format is still not > Latin-1-friendly (a complaint that also used to be brought > against UTF-8). Yes, you can only use UTF-8 or UTF-4 with legacy applications for windows-1252, not with applications needing the C1 control codes as is. He could use UTF-1 (it protects C0, SP, DEL, C1) or UTF-7. For my local purposes UTF-4 is fine, my text editor supports hex. I'm less good with modulo 64 for UTF-8 by heart, I need extra macros to decode / encode it. >> we can't use this for the registry, and we also won't try >> BOCU-1. But maybe IANA should offer a gzip-ped version. > BOCU-1 text tends to include a lot of bytes in the C1 range > (0x80 through 0x9F) and might not travel through e-mail very > well. It's as good or bad as UTF-8 (or in theory UTF-4) for that purpose, with 8BITMIME or news you need no CTE, otherwise you need B64 or QP. If e-mail has a problem with 8 bits these problems aren't limited to C1, it could be anything, likely a parity bit. > I still haven't received a clear answer about how patent- > encumbered BOCU-1 might be. IBM's statement in UTS #40 is "royalty-free". I didn't ask them for a US-license. In the EU and some other parts of the world it's AFAIK (and IANAL) a complete waste of time and money to patent algorithms. Patenting modulo 243 arithmetic is an odd idea. For UTF-4 (= modulo 16 with 64 lines CharMapML) it would be ridiculous (but one of these 64 lines is a copyright, just in case). > I like the gzip idea. lstreg6.txt 82218 (2006-08-04) lstreg6.txt.gz 11788 lstreg6.xml 104627 (see my reply to Debbie) lstreg6.xml.gz 12141 Matches your observations in UniCompress. For the 4646bis registry it makes sense for some folks (for me it's less relevant, the V.90 bottleneck has its own compression) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 08:11:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOCY2-0001iS-1v; Fri, 15 Sep 2006 08:11:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOCY0-0001iJ-SI for ltru@ietf.org; Fri, 15 Sep 2006 08:11:56 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOCXy-0004OG-LZ for ltru@ietf.org; Fri, 15 Sep 2006 08:11:56 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GOCXw-0002Pl-8B; Fri, 15 Sep 2006 08:11:52 -0400 Date: Fri, 15 Sep 2006 08:11:52 -0400 To: Martin Duerst Subject: Re: [Ltru] Re: script tag for IPA Message-ID: <20060915121152.GC25144@ccil.org> References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <6.0.0.20.2.20060915154910.06e040b0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060915154910.06e040b0@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > The solution proposed by Martin Hosken seems to make quite a bit > of sense to me. I only see two problems: > - This would need a change to the RFC 4646 ABNF. This is serious. Not a big one; basically we would need to allow multiple script subtags, just as we allow multiple variant subtags today. Order is enough to tell which is primary and which are secondary, so we need play no tricks with case; and there is no ambiguity, because currently a well-formed tag can have only one non-initial 4-letter subtag. I'm not necessarily saying I approve of this, just saying it's not a big deal technically. Changing the ABNF at all is indeed a big deal in terms of our commitments, however, so the sooner we decide to do this or not do this the better. -- John Cowan cowan@ccil.org ccil.org/~cowan Dievas dave dantis; Dievas duos duonos --Lithuanian proverb Deus dedit dentes; deus dabit panem --Latin version thereof Deity donated dentition; deity'll donate doughnuts --English version by Muke Tever God gave gums; God'll give granary --Version by Mat McVeagh _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 08:20:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOCfp-0004ZG-Ku; Fri, 15 Sep 2006 08:20:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOCfo-0004YO-7A for ltru@ietf.org; Fri, 15 Sep 2006 08:20:00 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOCfk-00051K-T5 for ltru@ietf.org; Fri, 15 Sep 2006 08:20:00 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 4D5C226C1F0; Fri, 15 Sep 2006 14:19:46 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 519D526C1DE; Fri, 15 Sep 2006 14:19:45 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 4E47958ED1C; Fri, 15 Sep 2006 14:19:45 +0200 (CEST) Date: Fri, 15 Sep 2006 14:19:45 +0200 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20060915121945.GA6110@nic.fr> References: <006d01c6d88d$82023950$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006d01c6d88d$82023950$6401a8c0@DGBP7M81> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: LTRU Working Group Subject: [Ltru] Re: Registry Format (was UTF-8) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Thu, Sep 14, 2006 at 11:09:29PM -0700, Doug Ewell wrote a message of 29 lines which said: > The multiple-value problem (for example, Description) is one reason we > abandoned the bar-delimited format. We would have had to choose one > ISO-provided description and ignore the rest: > > language | es | Spanish | 2005-10-16 | Latn | | > > or else use a subfield delimiter and pray it never appeared in real > descriptions: > > language | es | Spanish; Castilian | 2005-10-16 | Latn | | Or escape it, which is better than praying :-) Do note that, if you don't require round-trip perfection, non-escaping is perfectly valid, for instance: language | nv | Navajo / Navaho | 2005-10-16 | cannot be translated back to the record-jar registry (if / appears somewhere) but it may be a non-issue. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 08:22:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOCiA-00057i-VS; Fri, 15 Sep 2006 08:22:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOCi9-00057d-Ot for ltru@ietf.org; Fri, 15 Sep 2006 08:22:25 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOCi8-0005Jw-Hd for ltru@ietf.org; Fri, 15 Sep 2006 08:22:25 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GOCi8-0003XO-Ah; Fri, 15 Sep 2006 08:22:24 -0400 Date: Fri, 15 Sep 2006 08:22:24 -0400 To: Mark Davis Subject: Re: [Ltru] script tag for IPA Message-ID: <20060915122224.GD25144@ccil.org> References: <20060913202947.GC22114@ccil.org> <4508C6EC.90305@sil.org> <4508CD1A.9050405@sil.org> <4508DE16.3080607@yahoo-inc.com> <30b660a20609140839l4698d6c5lb7f8cdad1e47c9cc@mail.gmail.com> <20060914162137.GB20105@ccil.org> <30b660a20609141454m35ba8508n1021d5ba2437661a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20609141454m35ba8508n1021d5ba2437661a@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > What I get on the document if I ask for - or > -- is a ransom-note-look, a mixture of > orthographies. Even if the orthographies are legible, it is not a > professional result. I agree. > The reason for this is that the differences > between Hant and Hans, between polytonic and monotonic, etc. are much > larger than the differences between countries. I'm not convinced, at least when it comes to mixed-toniko orthography. I think that's a fault on about the same level as random mixtures of "labor" and "labour", "center" and "centre" in an English document. (Some very large documents actually tolerate this; no attempt is made to keep the English-language Wikipedia consistent in this way.) I simply don't think this is on the same scale as the badness of mixed Hans and Hant (which may be downright illegible if you don't read Hant), to say nothing of the badness of mixing proper Greek with frangovlaxika (gr-Latn). > So as a practical matter, where the othographic distinction rises to > the point where it is more important than the regional differences, > you want it first. It may be that toniko distinctions are more important *in Greek* than national ones, simply because national variants of Greek are thin on the ground; I don't know. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan O beautiful for patriot's dream that sees beyond the years Thine alabaster cities gleam undimmed by human tears! America! America! God mend thine every flaw, Confirm thy soul in self-control, thy liberty in law! -- one of the verses not usually taught in U.S. schools _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 09:45:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOE0p-0007ol-DU; Fri, 15 Sep 2006 09:45:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOE0n-0007lz-D9 for ltru@ietf.org; Fri, 15 Sep 2006 09:45:45 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GODoD-0007iY-Bd for ltru@ietf.org; Fri, 15 Sep 2006 09:32:46 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060915133117.FBFN23328.mta13.adelphia.net@DGBP7M81>; Fri, 15 Sep 2006 09:31:17 -0400 Message-ID: <008801c6d8cb$38f24500$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <6.0.0.20.2.20060915154910.06e040b0@localhost> Subject: Re: [Ltru] Re: script tag for IPA Date: Fri, 15 Sep 2006 06:31:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > The solution proposed by Martin Hosken seems to make quite a bit > of sense to me. I only see two problems: > - This would need a change to the RFC 4646 ABNF. This is serious. > - Everything related to lanuguage tags is case-insensitive. The > proposal below contains some case rules; these should (and can > easily) be dropped. - There are only 50 private-use code elements in ISO 15924, despite its huge capacity. We cannot "carve out" an area beyond this. Code elements starting with X and Z, for example, are already allocated. - This adds yet another mechanism that is expected to be of limited use -- if it's not for transliterations or transcriptions, it's probably just for IPA and IPA-like systems. Section 2.2.3 says we should be using variants for something like this. - The "priority" argument applies only if such a subtag is used with regions and if we assume nobody will use extended matching. -1. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 11:41:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFoe-0003vI-QR; Fri, 15 Sep 2006 11:41:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFoe-0003vD-44 for ltru@ietf.org; Fri, 15 Sep 2006 11:41:20 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOFoc-0002YY-PL for ltru@ietf.org; Fri, 15 Sep 2006 11:41:20 -0400 Received: from [10.72.72.2] (snvvpn1-10-72-72-c2.corp.yahoo.com [10.72.72.2]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8FFefSA090452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Sep 2006 08:40:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=MaOzCvQyLYfpvUXVY0uw2RcyAUNGjLC2YiwmzWZZPF7mNDR/ZYDDSysQGyEzQrTf Message-ID: <450AC979.3050203@yahoo-inc.com> Date: Fri, 15 Sep 2006 08:40:41 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Re: script tag for IPA References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <6.0.0.20.2.20060915154910.06e040b0@localhost> In-Reply-To: <6.0.0.20.2.20060915154910.06e040b0@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ltru@ietf.org, Doug Ewell X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > The solution proposed by Martin Hosken seems to make quite a bit > of sense to me. I only see two problems: > - This would need a change to the RFC 4646 ABNF. This is serious. > - Everything related to lanuguage tags is case-insensitive. The > proposal below contains some case rules; these should (and can > easily) be dropped. -1 Changing the ABNF is a horrible idea. The proper "repair" to this issue is to fix ISO 15924. Multiple script subtags would be very difficult for users to understand and use consistently. And we'd have to deal with canonical ordering rules, prefix checking, and all sorts of other nastiness---all to figure out which Latin transcription was used? Bah. Not to mention: if script variations aren't registered in 15924, where will they come from? What rules will be applied to their registration? Why does anyone think ietf-languages will be a good arbiter of said variations? Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 11:48:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFvT-0007Eo-Al; Fri, 15 Sep 2006 11:48:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFvR-0007DW-Np for ltru@lists.ietf.org; Fri, 15 Sep 2006 11:48:21 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOFvQ-0003Bh-Bh for ltru@lists.ietf.org; Fri, 15 Sep 2006 11:48:21 -0400 Received: from [10.72.72.2] (snvvpn1-10-72-72-c2.corp.yahoo.com [10.72.72.2]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8FFmIec090769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Sep 2006 08:48:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=Xh6KpvCHH714fUJdG4F4Ef3AtNF0TwF2jGtqHXjiry5lNBJbe1BbP2plwrUFJB/G Message-ID: <450ACB42.2050402@yahoo-inc.com> Date: Fri, 15 Sep 2006 08:48:18 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Martin Hosken Subject: Re: [Ltru] Re: script tag for IPA References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <450A6EEA.13A6@xyzzy.claranet.de> <450A77B8.5050603@sil.org> In-Reply-To: <450A77B8.5050603@sil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org >> Changing that is straight out. Better try a similar idea with >> an extension regitry, e.g. s-whatever for "script variants", or >> s-Latn-whatever for "Latn-variants" (etc.) >> > No because the script variation needs to come before region in priority > terms. Extensions can semantically modify whatever one wants them to in the language tag. An implementation is free to ignore an extension, whereupon it will fall off the tag first. > > In addition we need to indicate which extension marker marks a script > extension and which a language extension. No. You need to define what the semantics are for the specific extension. This could be that the extension describes script variation. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 11:54:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOG1l-0001Ue-MR; Fri, 15 Sep 2006 11:54:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOG1l-0001UY-1t for ltru@lists.ietf.org; Fri, 15 Sep 2006 11:54:53 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOG1j-00046b-NO for ltru@lists.ietf.org; Fri, 15 Sep 2006 11:54:53 -0400 Received: from [10.72.72.2] (snvvpn1-10-72-72-c2.corp.yahoo.com [10.72.72.2]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8FFskAM091025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Sep 2006 08:54:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=WpR5PjinHrPyQ+oYmMFHWgQxof4BeOSGMWdfFBOzqbvlQQe20PFS5iEHH79DZ7pJ Message-ID: <450ACCC6.30309@yahoo-inc.com> Date: Fri, 15 Sep 2006 08:54:46 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: UTF-8 References: <007501c6d890$b96ff410$6401a8c0@DGBP7M81> <450A8887.EAB@xyzzy.claranet.de> In-Reply-To: <450A8887.EAB@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This thread is very amusing, but, I think, not very useful. I think that using a widely-recognized, plain-text character encoding (UTF-8: "the new ASCII") would be a Good Thing. But changing which escape syntax we use, especially to use something, um, "unusual" like UTF-1 or BOCU-1, gives us nothing over using US-ASCII with some escape syntax (such as our existing NCR format). So: Is there any support for changing to UTF-8? Addison Frank Ellermann wrote: > Doug Ewell wrote: > >> I'm not sure why you chose 0x86 as your sequence introducer > > Six is the number of trailing octets: 91909F9F9F9F (for John's > example u+10FFFF). > >> you could make each sequence 1 byte shorter by marking the >> lead or trail byte specially > > Yes, but then only 2 octets (80+81) would never occur (instead > of 11), and lost 9x bytes won't cause an error. UTF-8 has now > 13 "impossible" octets, and similar features. > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 12:00:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOG75-0005A5-Fd; Fri, 15 Sep 2006 12:00:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOG6v-0004wp-OZ for ltru@ietf.org; Fri, 15 Sep 2006 12:00:13 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOG6u-0004de-Dc for ltru@ietf.org; Fri, 15 Sep 2006 12:00:13 -0400 Received: from [10.72.72.2] (snvvpn1-10-72-72-c2.corp.yahoo.com [10.72.72.2]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8FFxmbx087125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Sep 2006 08:59:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=udBYVUjg1e0nJ3HPyTanTqILGURRHVqT09BVMm0N7Pa2DdUFX0p44TnONY6viXmg Message-ID: <450ACDF4.10505@yahoo-inc.com> Date: Fri, 15 Sep 2006 08:59:48 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: script tag for IPA References: <003b01c6d885$934747d0$6401a8c0@DGBP7M81> In-Reply-To: <003b01c6d885$934747d0$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Doug Ewell wrote: > I note that the LTRU 2.0 charter says to consider possibilities for > tagging transliterations and transcriptions, specifically in the context > of extlangs and variants (I would add "or extensions"). It does *not* > say we should try to twist the arm of various ISO MA's and RA's to make > their standards fit our needs. If IPA does not fit the ISO 15924 > definition of "script," or if the Registrar and/or RA disagrees with > adding it, then that is that and it is not our business to change that. > > We saw something similar in LTRU 1.0 with ISO 3166. If ISO 3166/MA does > not find it within their policy to assign official country code elements > for non-country entities, such as the European Union or OPEC or NATO or > what have you, that is their call. We can and should ask them to take > stability measures that will not adversely affect their ability to > assign new code elements, but asking them to change the scope of the > standard goes well beyond that. We can suggest, but I don't think we > should flog. > > (Note that I completely avoided the question of whether IPA is a flavor > of Latin or a separate script; this was wholly intentional.) > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 12:06:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOGDF-0000ME-M8; Fri, 15 Sep 2006 12:06:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOGDE-0000M0-LG for ltru@ietf.org; Fri, 15 Sep 2006 12:06:44 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOGDD-0005AS-As for ltru@ietf.org; Fri, 15 Sep 2006 12:06:44 -0400 Received: from [10.72.72.2] (snvvpn1-10-72-72-c2.corp.yahoo.com [10.72.72.2]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8FG6GaV087476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Sep 2006 09:06:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=qDuMQ9brVvl5S7MUe4vvIiKPXdhNc9tTJOiKp8212dsgyhwQ72l6YdE7CaFQtqAY Message-ID: <450ACF78.4080909@yahoo-inc.com> Date: Fri, 15 Sep 2006 09:06:16 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Can't add a Preferred-Value to a redundant tag References: <003c01c6d637$6e6c6260$6401a8c0@DGBP7M81> <4506D714.4020705@yahoo-inc.com> <004301c6d6e1$72276d50$6401a8c0@DGBP7M81> <450826A0.2000206@yahoo-inc.com> <30b660a20609130901q18d1e97eu2370953c30d34062@mail.gmail.com> <005601c6d803$01e627c0$6401a8c0@DGBP7M81> <45097776.4090800@yahoo-inc.com> <002d01c6d870$0bb62120$6401a8c0@DGBP7M81> In-Reply-To: <002d01c6d870$0bb62120$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > >> But ultimately, I think the best course of action is: >> >> 1. Allow the registered meaning to remain, keeping the description >> (even though it could be broadened). Consider it historical. > > Figuratively, of course. There is no such formal category in the > Registry (like "Deprecated") and I assume you are not proposing one. Yes, of course. "Type: redundant" is pretty much "historical" anyway. -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 14:42:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIdi-0007Ns-K8; Fri, 15 Sep 2006 14:42:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIdh-0007Nn-6a for ltru@lists.ietf.org; Fri, 15 Sep 2006 14:42:13 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIdf-0008Dv-PK for ltru@lists.ietf.org; Fri, 15 Sep 2006 14:42:13 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id C00DF1E1470; Fri, 15 Sep 2006 11:42:08 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Fri, 15 Sep 2006 11:42:08 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Addison Phillips' , Frank Ellermann Subject: RE: [Ltru] Re: UTF-8 Date: Fri, 15 Sep 2006 11:42:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, I support changing to unescaped UTF-8 for the registry (consistent with the IESG policy in BCP 18 / RFC 2277). But I also think Doug has it right that zipped content as MIME attachments would be better, because the various deployed email systems make raw UTF-8 (or any other UTF) totally unreliable. And if we move to XML with IANA concurrence, we'll get UTF-8 anyway. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: Friday, September 15, 2006 11:55 AM > To: Frank Ellermann > Cc: ltru@lists.ietf.org > Subject: Re: [Ltru] Re: UTF-8 > > > This thread is very amusing, but, I think, not very useful. I > think that > using a widely-recognized, plain-text character encoding (UTF-8: "the > new ASCII") would be a Good Thing. But changing which escape > syntax we > use, especially to use something, um, "unusual" like UTF-1 or BOCU-1, > gives us nothing over using US-ASCII with some escape syntax (such as > our existing NCR format). > > So: > > Is there any support for changing to UTF-8? > > Addison > > Frank Ellermann wrote: > > Doug Ewell wrote: > > > >> I'm not sure why you chose 0x86 as your sequence introducer > > > > Six is the number of trailing octets: 91909F9F9F9F (for John's > > example u+10FFFF). > > > >> you could make each sequence 1 byte shorter by marking the > >> lead or trail byte specially > > > > Yes, but then only 2 octets (80+81) would never occur (instead > > of 11), and lost 9x bytes won't cause an error. UTF-8 has now > > 13 "impossible" octets, and similar features. > > > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.4/449 - Release Date: 9/15/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 18:41:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOMNQ-0000ZF-1W; Fri, 15 Sep 2006 18:41:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOMNP-0000ZA-9u for ltru@lists.ietf.org; Fri, 15 Sep 2006 18:41:39 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOMNN-0002dY-TZ for ltru@lists.ietf.org; Fri, 15 Sep 2006 18:41:39 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GOMMx-0000yq-OI for ltru@lists.ietf.org; Sat, 16 Sep 2006 00:41:11 +0200 Received: from pd9fbadab.dip0.t-ipconnect.de ([217.251.173.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Sep 2006 00:41:11 +0200 Received: from nobody by pd9fbadab.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Sep 2006 00:41:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 16 Sep 2006 00:38:45 +0200 Organization: Lines: 30 Message-ID: <450B2B75.2F36@xyzzy.claranet.de> References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbadab.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org McDonald, Ira wrote: > I support changing to unescaped UTF-8 for the registry I'm opposed. > (consistent with the IESG policy in BCP 18 / RFC 2277). That's about new protocols, not text/plain files like RFCs or the LTRU registry. > if we move to XML with IANA concurrence, we'll get UTF-8 > anyway. Several issues here: Where does the "IANA will convert everything to XML" rumour come from? I saw no discussion about this on the XML-dir list. Numerous RFCs define registries with text/plain registration templates, if those templates are anything it's a kind of "record-jar". IANA can't simply reformat all their registries when they feel like it. XML is perfectly able to support any charset. UTF-16 and UTF-8 are only the minimally supported encodings. With the required UTF-8 support implementations not supporting US-ASCII would be odd. For something like xml2rfc stupid. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 18:56:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOMbq-0007Db-Nd; Fri, 15 Sep 2006 18:56:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOMbp-0007CE-SG for ltru@lists.ietf.org; Fri, 15 Sep 2006 18:56:33 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOMbo-0005Uv-EE for ltru@lists.ietf.org; Fri, 15 Sep 2006 18:56:33 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GOMbg-0003mI-Pt for ltru@lists.ietf.org; Sat, 16 Sep 2006 00:56:24 +0200 Received: from pd9fbadab.dip0.t-ipconnect.de ([217.251.173.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Sep 2006 00:56:24 +0200 Received: from nobody by pd9fbadab.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Sep 2006 00:56:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 16 Sep 2006 00:54:31 +0200 Organization: Lines: 84 Message-ID: <450B2F27.FD7@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbadab.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.2 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Subject: [Ltru] DOCTYPE ltru X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org For the XML fans, below you find a possible DTD for the ltru2xml script posted yesterday. I've never tried that before, probably it's clumsy. The W3C validator accepts it for a converted registry. Frank ]> Afar _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 19:54:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GONVm-0001CR-8a; Fri, 15 Sep 2006 19:54:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GONVl-0001Ap-Gz for ltru@ietf.org; Fri, 15 Sep 2006 19:54:21 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GONTP-0002kt-0W for ltru@ietf.org; Fri, 15 Sep 2006 19:51:56 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GONTM-00088F-LV; Fri, 15 Sep 2006 19:51:52 -0400 Date: Fri, 15 Sep 2006 19:51:52 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: script tag for IPA Message-ID: <20060915235152.GG25144@ccil.org> References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <6.0.0.20.2.20060915154910.06e040b0@localhost> <008801c6d8cb$38f24500$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008801c6d8cb$38f24500$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > - There are only 50 private-use code elements in ISO 15924, despite its > huge capacity. We cannot "carve out" an area beyond this. Code > elements starting with X and Z, for example, are already allocated. The capacity is not so large as it looks. Every 4-letter code has a corresponding 3-digit code, so the absolute limit is 1000 scripts, and the first digit of the numeric code encodes the type of script according to the following table: 0 - hieroglyphic/cuneiform 1 - RTL alphabets/abjads 2 - LTR alphabets/abjads 3 - abugidas 4 - syllabaries 5 - morphosyllabaries 6 - undeciphered 9 - private use, alias, special -- Yes, chili in the eye is bad, but so is your John Cowan ear. However, I would suggest you wash your cowan@ccil.org hands thoroughly before going to the toilet. http://www.ccil.org/~cowan --gadicath _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 15 22:26:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOPtT-0004Px-4g; Fri, 15 Sep 2006 22:26:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOPtS-0004Ps-66 for ltru@ietf.org; Fri, 15 Sep 2006 22:26:58 -0400 Received: from smtp1.wsfo.org ([208.145.81.52] helo=smtp2.wsfo.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOPtM-00067t-Sd for ltru@ietf.org; Fri, 15 Sep 2006 22:26:58 -0400 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp2.wsfo.org (8.13.1/8.13.1) with ESMTP id k8G2QY5E011999 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Fri, 15 Sep 2006 22:26:34 -0400 X-Scanned-By: MIMEDefang 2.54 on 172.22.0.52 X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp X-Scanned-By: This message was scanned by MPP Free Edition (www.messagepartners.com)! Received: from [203.154.52.122] (account martin_hosken@sil.org HELO [192.168.1.6]) by mail.link77.net (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 122829201; Fri, 15 Sep 2006 22:26:33 -0400 Message-ID: <450B60D4.1040401@sil.org> Date: Sat, 16 Sep 2006 09:26:28 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Re: script tag for IPA References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <6.0.0.20.2.20060915154910.06e040b0@localhost> <450AC979.3050203@yahoo-inc.com> In-Reply-To: <450AC979.3050203@yahoo-inc.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Doug Ewell , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear Addison, > > The proper "repair" to this issue is to fix ISO 15924. Multiple script > subtags would be very difficult for users to understand and use > consistently. And we'd have to deal with canonical ordering rules, > prefix checking, and all sorts of other nastiness---all to figure out > which Latin transcription was used? Bah. The registrar of ISO 15924 has indicated that he has no intention of ever giving IPA a script code and that it is a variant of Latn. Perhaps you can get him to change his mind, but I doubt it. So where does that leave me? How do I tag text in the IPA script that can be in any language? You are asking me to live between a rock and a hard place. As Mark has stated, we need something to indicate that a script variant is more significant than a region. For example, please prioritise the aspects of "UK Glaswegian English written in IPA" in terms of the components that have the most significance on the text and you will find that UK comes last and Glaswegian second to last. But if IPA is marked by an extension, it will come last. I estimate that there are probably in the order of 10 scripts needing on average 2-3 variants each. But that depends on what we see as being a script variant. In discussions with the ISO 15924 registrar on this, he seemed open to the idea of extending the private use script code space. In addition, I agree that since a script variant (in my 4 character scheme) would always occur after a real script, there is no need to worry about codespace overlap. > > Not to mention: if script variations aren't registered in 15924, where > will they come from? What rules will be applied to their registration? > Why does anyone think ietf-languages will be a good arbiter of said > variations? ISO 15924 hasn't scored too highly for us so far. Addressing what a script variant really is will need some discussion, of course. Remember that ISO 15924 isn't our standard to control. It's coming from TC46. In the meantime, please send me the form to request 7000 language variants or extensions (since both are registered by language). I would encourage folks to think about how the language tag can be made productive. If every possible language tag in effect has to be registered, it will push many tags underground and the x- extension space will become far more popular than we might want it to be. I, for example, have to deal with emerging writing systems and storing data in them for archival purposes long before such writing systems are well established (in some cases), if every such instance needs to be registered RFC4646 will be seen as a bottle kneck to be worked around rather than in collaboration with. Yours, Martin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 00:14:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GORZ1-0001tg-Hu; Sat, 16 Sep 2006 00:13:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GORZ0-0001tB-Rg for ltru@ietf.org; Sat, 16 Sep 2006 00:13:58 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GORYz-0006mW-Jx for ltru@ietf.org; Sat, 16 Sep 2006 00:13:58 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060916041351.TJET27224.mta10.adelphia.net@DGBP7M81>; Sat, 16 Sep 2006 00:13:51 -0400 Message-ID: <003b01c6d946$85040890$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <6.0.0.20.2.20060915154910.06e040b0@localhost> <008801c6d8cb$38f24500$6401a8c0@DGBP7M81> <20060915235152.GG25144@ccil.org> Subject: Re: [Ltru] Re: script tag for IPA Date: Fri, 15 Sep 2006 21:13:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >> - There are only 50 private-use code elements in ISO 15924, despite >> its huge capacity. We cannot "carve out" an area beyond this. Code >> elements starting with X and Z, for example, are already allocated. > > The capacity is not so large as it looks. Every 4-letter code has a > corresponding 3-digit code, so the absolute limit is 1000 scripts Seen in that light, the percentage of total ISO 15924 code space allocated to private use (5.0 percent) compares well to ISO 639 (2.9 percent), ISO 3166 (6.2 percent), and ISO 10646 (12.3 percent). This is much better than 50 out of 456,976 possible 4-letter code elements, or 0.00011 percent. We still can't unilaterally carve out an area of the ISO 15924 code space for our own purposes. I'd be tempted to write an RFC for the t- extension myself, as convinced as I am that that's the path we should be taking, but I'd have to set up and moderate a discussion mailing list and I have no time for that. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 00:22:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GORhR-0005VQ-CE; Sat, 16 Sep 2006 00:22:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GORhQ-0005Uj-GA for ltru@ietf.org; Sat, 16 Sep 2006 00:22:40 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GORhP-0007MJ-8P for ltru@ietf.org; Sat, 16 Sep 2006 00:22:40 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060916042238.ZGBY10468.mta9.adelphia.net@DGBP7M81>; Sat, 16 Sep 2006 00:22:38 -0400 Message-ID: <004301c6d947$bef6f980$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <6.0.0.20.2.20060915154910.06e040b0@localhost> <450AC979.3050203@yahoo-inc.com> <450B60D4.1040401@sil.org> Subject: Re: [Ltru] Re: script tag for IPA Date: Fri, 15 Sep 2006 21:22:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Hosken wrote: > The registrar of ISO 15924 has indicated that he has no intention of > ever giving IPA a script code and that it is a variant of Latn. > Perhaps you can get him to change his mind, but I doubt it. So where > does that leave me? How do I tag text in the IPA script that can be in > any language? You are asking me to live between a rock and a hard > place. EXTENSIONS. Somebody read Section 3.7, please. This mechanism was added for a reason. > As Mark has stated, we need something to indicate that a script > variant is more significant than a region. For example, please > prioritise the aspects of "UK Glaswegian English written in IPA" in > terms of the components that have the most significance on the text > and you will find that UK comes last and Glaswegian second to last. > But if IPA is marked by an extension, it will come last. Then it would be really silly to include a region subtag, wouldn't it? > In the meantime, please send me the form to request 7000 language > variants or extensions (since both are registered by language). You're kidding, of course. You really have examples of 7,000 languages written in IPA? Awyi and Brokskat and Caluyanun and Dusner and all the rest? Is everyone aware that extension subtags are NOT required to be specific to a single language? -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 00:50:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOS8b-0001OP-JP; Sat, 16 Sep 2006 00:50:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOS8a-0001O3-KH for ltru@ietf.org; Sat, 16 Sep 2006 00:50:44 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GORxt-0000JZ-Bk for ltru@ietf.org; Sat, 16 Sep 2006 00:39:42 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060916043940.FLUE10574.mta13.adelphia.net@DGBP7M81> for ; Sat, 16 Sep 2006 00:39:40 -0400 Message-ID: <005301c6d94a$201174a0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 15 Sep 2006 21:39:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > This thread is very amusing, but, I think, not very useful. That's why I marked my last post on it [OT]. > I think that using a widely-recognized, plain-text character encoding > (UTF-8: "the new ASCII") would be a Good Thing. But changing which > escape syntax we use, especially to use something, um, "unusual" like > UTF-1 or BOCU-1, gives us nothing over using US-ASCII with some escape > syntax (such as our existing NCR format). More to the point, changing from record-jar with hex NCR's to *anything* else has to be not just better, but "better enough." The pain and instability caused by the change must be considered, and the benefits must outweigh them. > So: > > Is there any support for changing to UTF-8? I would support it on two conditions: 1. We must be able to use UTF-8 in the I-D (4645bis) that delivers the Registry contents to IANA. (It's OK if that means the I-D can't be an RFC.) Asking IANA to convert NCR's into UTF-8 themselves would be a disaster. The new Registry will have almost 500 non-ASCII characters. 2. We have to maintain compatibility with the existing format, which means we must continue to escape the ampersand as & if one should ever find its way into the Registry. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 00:53:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOSAt-0002cm-Gi; Sat, 16 Sep 2006 00:53:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOSAs-0002cg-RL for ltru@lists.ietf.org; Sat, 16 Sep 2006 00:53:06 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOSAr-0001fH-DD for ltru@lists.ietf.org; Sat, 16 Sep 2006 00:53:06 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GOSAp-0001Qa-B6 for ltru@lists.ietf.org; Sat, 16 Sep 2006 06:53:03 +0200 Received: from pd9fba8d0.dip0.t-ipconnect.de ([217.251.168.208]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Sep 2006 06:53:03 +0200 Received: from nobody by pd9fba8d0.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Sep 2006 06:53:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 16 Sep 2006 06:49:54 +0200 Organization: Lines: 62 Message-ID: <450B8272.52B2@xyzzy.claranet.de> References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <6.0.0.20.2.20060915154910.06e040b0@localhost> <450AC979.3050203@yahoo-inc.com> <450B60D4.1040401@sil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8d0.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Subject: [Ltru] Re: script tag for IPA X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Hosken wrote: > The registrar of ISO 15924 has indicated that he has no > intention of ever giving IPA a script code and that it is a > variant of Latn. Perhaps you can get him to change his mind, > but I doubt it. For the Unicode Consortium (the ISO 15924/RA) I've no idea how appeals work. You probably need a rejected "Latp" registration request, and arguments why that decision violates ISO 15924 (?) > As Mark has stated BTW, Mark certainly knows everything about any "Unicode appeal process", if it exists. Almost all contributors here are in some way Unicode members, Randy (maybe) and I are exceptions. If they don't know how to overrule their appointed registrar - maybe he's simply right and IPA is no script or variant as defined in the standard ? I've just read the page about the ISO 15924 history - the author of the rules would know what they mean. For RFC 4646bis I hope that we'll add a requirement that the subtag reviewer MUST indicate that (s)he has read the RFC, and is willing to implement it, and is appointed for a defined period of time, ideally by the IETF NomCom. Or something in that direction, making sure that the reviewer has still read and write access on the review list - at the moment that isn't relevant for the language list, but for other review lists it can be an issue if they're silent for months (or even years). > In discussions with the ISO 15924 registrar on this, he > seemed open to the idea of extending the private use script > code space. Apparently there's also the possibility to reserve codes if they are rejected by the JAC. At the moment that won't help you, because reserved codes can't be used in language tags - same idea as EU wrt country codes. "Officially", of course you're always free to do what you want as long as you don't claim to follow rules after you've clearly broken them... :-) > In addition, I agree that since a script variant (in my 4 > character scheme) would always occur after a real script, > there is no need to worry about codespace overlap. It would break all 4646 parsers. It would also break a main feature of 4646, minus grandfathered cruft you can decompose a tag into subtags, and you always know what each subtag is if you keep the leading hyphen: -1234 => must be a variant, -abcd => must be a script, -123 => must be an UN M.49 number, -ab => must be a 3166 CC, -abc => extlang, abc => language, ab => language, abcd => language (not yet possible), etc. You can also recreate the original tag from its pieces to a certain degree. For extlang and variant you need the prefix as noted in the registry, for generic variants you lose, but maybe 4646bis kills generic variants by one s/SHOULD/MUST/. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 04:08:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOVDV-0007lU-NF; Sat, 16 Sep 2006 04:08:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOVDT-0007lD-Rd for ltru@lists.ietf.org; Sat, 16 Sep 2006 04:07:59 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOVDS-00022q-9U for ltru@lists.ietf.org; Sat, 16 Sep 2006 04:07:59 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GOVDP-0000XE-TL for ltru@lists.ietf.org; Sat, 16 Sep 2006 10:07:55 +0200 Received: from pd9fba8e3.dip0.t-ipconnect.de ([217.251.168.227]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Sep 2006 10:07:55 +0200 Received: from nobody by pd9fba8e3.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Sep 2006 10:07:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 16 Sep 2006 10:04:22 +0200 Organization: Lines: 99 Message-ID: <450BB006.4FFD@xyzzy.claranet.de> References: <450B2F27.FD7@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8e3.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.2 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Subject: [Ltru] Re: DOCTYPE ltru X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > For the XML fans, below you find a possible DTD Now I tried to add the XREF feature from my REXX registry validator to the DTD (see below). That resulted in three special cases: zh-cmn We have no extlang cmn at the moment, therefore I got a missing ID _cmn. Problem disabled by special hack. zh-hakka Similar, but there will be no _hakka variant, the "missing" ID _hakka has to be permanently disabled. The grandfathered zh-cmn and zh-hakka of course exist, but my parser tries to decompose such tags into IDREFS. The third problem is apparently a bug in the registry: missing ID _latn (small L) in yi-latn. For the REXX validator I never saw that because it internally works case-insensitive, but with XML ID _latn is not _Latn. Frank ]> Afar Taiwan Chinese in traditional script _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 05:24:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOWP3-0004Ig-FE; Sat, 16 Sep 2006 05:24:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOWP2-0004Hp-Mb for ltru@lists.ietf.org; Sat, 16 Sep 2006 05:24:00 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOWOz-0004m6-B3 for ltru@lists.ietf.org; Sat, 16 Sep 2006 05:24:00 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8G9NfCt022325 for ; Sat, 16 Sep 2006 18:23:41 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 4148_0aa6c2dc_4565_11db_8cd0_0014221f2a2d; Sat, 16 Sep 2006 18:23:40 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:57605) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 16 Sep 2006 18:23:46 +0900 Message-Id: <6.0.0.20.2.20060916114849.081056e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 16 Sep 2006 12:03:15 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: UTF-8 In-Reply-To: <450B2B75.2F36@xyzzy.claranet.de> References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 07:38 06/09/16, Frank Ellermann wrote: >McDonald, Ira wrote: > >> I support changing to unescaped UTF-8 for the registry > >I'm opposed. It would be good to know why. >> (consistent with the IESG policy in BCP 18 / RFC 2277). > >That's about new protocols, not text/plain files like >RFCs or the LTRU registry. Yes indeed. This means that Ira's argument is a bit weak, but does not give an argument for not using UTF-8. >> if we move to XML with IANA concurrence, we'll get UTF-8 >> anyway. > >Several issues here: Where does the "IANA will convert >everything to XML" rumour come from? I saw no discussion >about this on the XML-dir list. Numerous RFCs define >registries with text/plain registration templates, if >those templates are anything it's a kind of "record-jar". > >IANA can't simply reformat all their registries when they >feel like it. As a co-chair, I feel that this is rather irrelevant: Our charter's timeline is short, and any attempt by IANA to convert to 'all-XML' will be a long-time effort, if it is done. If somebody wants to argue for XML, they should do so based on it's merits. As a technical contributor, I think that UTF-8 is the right way to go, but otherwise, we should keep the format as is. Looking at something like Bokmål is just plain annoying. I'm sure the logistic problems with IANA can be sorted out (e.g. using attachments). As for using compression, this can be done mostly transparently. browsers tell servers what encodings they support, e.g. like so: Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 The server can be configured to send the appropriatly encoded version of the file. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 06:44:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOXeS-0008MZ-BK; Sat, 16 Sep 2006 06:44:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOXeR-0008MO-73 for ltru@lists.ietf.org; Sat, 16 Sep 2006 06:43:59 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOXeM-0006VZ-Nn for ltru@lists.ietf.org; Sat, 16 Sep 2006 06:43:59 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GOXeJ-000547-P6 for ltru@lists.ietf.org; Sat, 16 Sep 2006 12:43:51 +0200 Received: from pd9fba8e3.dip0.t-ipconnect.de ([217.251.168.227]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Sep 2006 12:43:51 +0200 Received: from nobody by pd9fba8e3.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Sep 2006 12:43:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 16 Sep 2006 12:34:47 +0200 Organization: Lines: 56 Message-ID: <450BD347.9EA@xyzzy.claranet.de> References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> <6.0.0.20.2.20060916114849.081056e0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8e3.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: [UTF-8 registry] >> I'm opposed. > It would be good to know why. ftp://ftp.iana.org/assignments/language-subtag-registry I've no clue what FTP clients would do with something like that. John's "net-UTF-8" draft isn't ready, and I had some troubles to understand his last published version. Another issue are fonts, for RFC 4646 there were proposals to restrict the registry to Latn. Fortunately that was dropped, because the problem doen't exist with US-ASCII plus NCRs. > something like Bokmål is just plain annoying. At least we know what this is. Bokm=C3=A5l is less clear - raw UTF-8 displayed as Latin-1, http://purl.net/net/ucode/E5 > I'm sure the logistic problems with IANA can be sorted > out (e.g. using attachments). Yes. I doubt that there is any logistic problem for mail submissions. Only for the bulk update, the fattest I-D in the history of the Internet using B64, they'd shoot us. We could try QP, and silently send them Doug's original data (as mail) in addition to the I-D. But as you said, that can be sorted out, it's not the reason why I prefer to stick to the format as is. We've no clear idea which tools will exist for the 4646 format in six months, how they do their updates (http or ftp), and what local conversions they use. Doug already proposed that an UTF-8 version might have to keep the & convention, that could be confusing. And we'd have to decide if a signature is required, another change of the record-jar ABNF. > compression, this can be done mostly transparently. > browsers tell servers what encodings they support, e.g. > like so: > Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=3D0 ACK, I forgot this, my favourite browser uses HTTP/1.0 ;-) An explicit gzip variant could still make sense for ftp and HTTP/1.0 (?) We can add some "IANA might consider to offer" blurb in the IANA considerations, but IMO we can't tell them how to run their servers. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 11:32:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOc9o-000695-KX; Sat, 16 Sep 2006 11:32:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOc9n-000690-QU for ltru@ietf.org; Sat, 16 Sep 2006 11:32:39 -0400 Received: from smtp1.wsfo.org ([208.145.81.52] helo=smtp2.wsfo.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOc9m-0008LM-8Z for ltru@ietf.org; Sat, 16 Sep 2006 11:32:39 -0400 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp2.wsfo.org (8.13.1/8.13.1) with ESMTP id k8GFWGoB002905 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Sat, 16 Sep 2006 11:32:16 -0400 X-Scanned-By: MIMEDefang 2.54 on 172.22.0.52 X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp X-Scanned-By: This message was scanned by MPP Free Edition (www.messagepartners.com)! Received: from [203.150.117.209] (account martin_hosken@sil.org HELO [192.168.1.6]) by mail.link77.net (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 122853264; Sat, 16 Sep 2006 11:32:16 -0400 Message-ID: <450C18FA.3090500@sil.org> Date: Sat, 16 Sep 2006 22:32:10 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: script tag for IPA References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <6.0.0.20.2.20060915154910.06e040b0@localhost> <450AC979.3050203@yahoo-inc.com> <450B60D4.1040401@sil.org> <004301c6d947$bef6f980$6401a8c0@DGBP7M81> In-Reply-To: <004301c6d947$bef6f980$6401a8c0@DGBP7M81> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear Doug, > > You're kidding, of course. Yes I'm kidding about filling out the forms. But I am serious that we need to mark IPA for everything. > You really have examples of 7,000 languages written in IPA? Not yet, no. But hang on. The process of identifying a language for inclusion in the Ethnologue involves a process called survey. They primary means of doing survey is to take wordlists from locations and transcribe them into IPA, so that they can be cross compared. So the probability is that there exists some text somewhere in IPA for nearly all these languages. So, in summary, yes we need IPA for all languages. > Awyi and Brokskat and Caluyanun and Dusner and all the rest? Having looked at their entries in the Ethnologue, I would be surprised if no wordlist had been taken and therefore surprised if there were not some text in IPA in those languages. Please excuse my playful pedantry on that one :) Yours, Martin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 12:07:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOchW-0003vt-AL; Sat, 16 Sep 2006 12:07:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOchV-0003v8-QD for ltru@ietf.org; Sat, 16 Sep 2006 12:07:29 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOchU-0006ab-JV for ltru@ietf.org; Sat, 16 Sep 2006 12:07:29 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GOchP-0007qW-Tr; Sat, 16 Sep 2006 12:07:23 -0400 Date: Sat, 16 Sep 2006 12:07:23 -0400 To: Martin Duerst Subject: Re: [Ltru] Re: UTF-8 Message-ID: <20060916160723.GB25175@ccil.org> References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> <6.0.0.20.2.20060916114849.081056e0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060916114849.081056e0@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > As a technical contributor, I think that UTF-8 is the right > way to go, but otherwise, we should keep the format as is. > Looking at something like Bokmål is just plain annoying. > I'm sure the logistic problems with IANA can be sorted out > (e.g. using attachments). I am more skeptical about the ability of everyone involved to keep everything encoded correctly, and repeat into the indefinite future; consequently, I prefer the current escaping scheme. After all, UTF-8 was as useful *and* as problematic when we adopted the scheme a year or two ago as it is today: nothing has changed, so we should change nothing. -- John Cowan http://ccil.org/~cowan cowan@ccil.org 'Tis the Linux rebellion / Let coders take their place, The Linux-nationale / Shall Microsoft outpace, We can write better programs / Our CPUs won't stall, So raise the penguin banner of / The Linux-nationale. --Greg Baker _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 13:12:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOdiD-0005jF-OO; Sat, 16 Sep 2006 13:12:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOdiC-0005jA-Ky for ltru@ietf.org; Sat, 16 Sep 2006 13:12:16 -0400 Received: from mta5.adelphia.net ([68.168.78.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOdiB-0002mw-Do for ltru@ietf.org; Sat, 16 Sep 2006 13:12:16 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060916170950.PRON28624.mta11.adelphia.net@DGBP7M81> for ; Sat, 16 Sep 2006 13:09:50 -0400 Message-ID: <008201c6d9b2$ebfd2600$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 16 Sep 2006 10:09:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ltru] Re: DOCTYPE ltru X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > The third problem is apparently a bug in the registry: > missing ID _latn (small L) in yi-latn. For the REXX > validator I never saw that because it internally works > case-insensitive, but with XML ID _latn is not _Latn. It's capitalized that way because it was registered that way under RFC 3066. It was the first tag to be registered with a script component, and at the time it was not (widely) known that RFC 3066 would be updated to include productive script subtags using This casing convention. In building the initial Registry, I considered that "yi-latn" qualified under Section 2, item 7 of RFC 4645 even though the capitalization was different. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 13:16:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOdmK-00074q-UK; Sat, 16 Sep 2006 13:16:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOdmK-00074O-1Y for ltru@ietf.org; Sat, 16 Sep 2006 13:16:32 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOdmI-00039b-Q0 for ltru@ietf.org; Sat, 16 Sep 2006 13:16:32 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060916171630.PXDC28624.mta11.adelphia.net@DGBP7M81> for ; Sat, 16 Sep 2006 13:16:30 -0400 Message-ID: <008801c6d9b3$da4b9e40$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 16 Sep 2006 10:16:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: >>> (consistent with the IESG policy in BCP 18 / RFC 2277). >> >>That's about new protocols, not text/plain files like RFCs or the LTRU >>registry. > > Yes indeed. This means that Ira's argument is a bit weak, but does not > give an argument for not using UTF-8. There are two separate issues being discussed here: 1. whether the Registry format should be changed to XML (or another file format) 2. whether the Registry should use UTF-8 directly instead of hex NCRs If we change to XML, we will be automatically allowed (though not required) to change to UTF-8, but the opposite is not true: changing to UTF-8 does not imply switching away from record-jar. Let's discuss these issues separately as needed to avoid confusion and misunderstanding. BTW, I keep seeing references to the Registry being in "modified record-jar." Would someone please refresh my memory: What is "modified" about the Registry's format as compared to "standard" record-jar? -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 13:30:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOdzu-0004r1-AB; Sat, 16 Sep 2006 13:30:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOdzt-0004qw-8K for ltru@ietf.org; Sat, 16 Sep 2006 13:30:33 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOdzr-0004LV-V9 for ltru@ietf.org; Sat, 16 Sep 2006 13:30:33 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060916173031.TUCD10574.mta13.adelphia.net@DGBP7M81> for ; Sat, 16 Sep 2006 13:30:31 -0400 Message-ID: <009601c6d9b5$cf9defa0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <6.0.0.20.2.20060915154910.06e040b0@localhost> <450AC979.3050203@yahoo-inc.com> <450B60D4.1040401@sil.org> <004301c6d947$bef6f980$6401a8c0@DGBP7M81> <450C18FA.3090500@sil.org> Date: Sat, 16 Sep 2006 10:30:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ltru] IPA and other transcriptions (was: Re: script tag for IPA) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Hosken brings up a good case for the existence of text written in, if not 7,000 languages, at least a large percentage of them, using IPA. Let me ask a general, related question. We have talked about Wade-Giles and pinyin, and to a much lesser extent McCune-Reischauer and ALA-LC and ISO 9 and other standards and/or conventions for transcribing and/or transliterating languages into a different writing system (not, not "script") for some purpose. In what way -- other than the actual repertoire of characters used -- do IPA and other phonetic and phonemic notation systems, differ from those? -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 13:56:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOeOv-0005ao-Ms; Sat, 16 Sep 2006 13:56:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOeOu-0005ZX-8N for ltru@ietf.org; Sat, 16 Sep 2006 13:56:24 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOeOt-0006wD-Lk for ltru@ietf.org; Sat, 16 Sep 2006 13:56:24 -0400 Received: from [10.72.72.7] (snvvpn1-10-72-72-c7.corp.yahoo.com [10.72.72.7]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8GHtnEQ048435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Sep 2006 10:55:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=E88ivhGEvfenGlvlco3taQkAwJSGngY0QXh67S5Y4bgzoOBMLs3A+WG1fdmHvV4r Message-ID: <450C3AA4.20209@yahoo-inc.com> Date: Sat, 16 Sep 2006 10:55:48 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Martin Hosken Subject: Re: [Ltru] Re: script tag for IPA References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <6.0.0.20.2.20060915154910.06e040b0@localhost> <450AC979.3050203@yahoo-inc.com> <450B60D4.1040401@sil.org> In-Reply-To: <450B60D4.1040401@sil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: Doug Ewell , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Hosken wrote: >> The proper "repair" to this issue is to fix ISO 15924. Multiple script >> subtags would be very difficult for users to understand and use >> consistently. And we'd have to deal with canonical ordering rules, >> prefix checking, and all sorts of other nastiness---all to figure out >> which Latin transcription was used? Bah. > > The registrar of ISO 15924 has indicated that he has no intention of > ever giving IPA a script code and that it is a variant of Latn. Perhaps > you can get him to change his mind, but I doubt it. So where does that > leave me? How do I tag text in the IPA script that can be in any > language? You are asking me to live between a rock and a hard place. Very few ISO standards are entirely under the thumb of one person's opinion. Just because Michael indicated his opposition on an unaffiliated email list doesn't mean that a carefully prepared request to ISO 15924 would fail. I'm not asking you to live between a Scylla and Charybdis. I'm asking you to carefully consider what you're asking for. The idea you presented would break a number of principles and commitments in the formation of language tags. Furthermore, I note that ietf-languages history as a registry is somewhat uneven---something that was reined in under RFC 4646 on purpose. I also note that adding more complex and arcane structures to language tags strikes me as questionable. The "finger of doubt" points at 15924 as the source of scripts. I would exhaust that angle first. > > As Mark has stated, we need something to indicate that a script variant > is more significant than a region. For starters, I don't believe in "script variants". I think there is a disconnect between the granularity of "script" as currently embodied in 15924 and "script" as needed in language tags. Mark and I were of the (possibly mistaken) impression that 15924 would be a bit more expansive in their interpretation of "script". > For example, please prioritise the > aspects of "UK Glaswegian English written in IPA" in terms of the > components that have the most significance on the text and you will find > that UK comes last and Glaswegian second to last. But if IPA is marked > by an extension, it will come last. So? Language tags cannot do everything. At some point one must look at the fact that two bodies of text have different tags and concluded that they are different, possibly mutually unintelligible, entities. RFC 4646 even says this in Section 4.2. While the relative importance of various subtags is a key feature, there may be times that the subtags cannot entirely reflect the real relationships of the variations. And I think the correct resolution to the problem would be to get 15924 to register additional codes or to get a source for codes that mirrors 15924 while adding additional codes to suit the needs of (say) language and locale identification. "en-Lipa-GB-glasgow" would be the best solution to your conundrum. > > In discussions with the ISO 15924 registrar on this, he seemed open to > the idea of extending the private use script code space. In addition, I > agree that since a script variant (in my 4 character scheme) would > always occur after a real script, there is no need to worry about > codespace overlap. Script "variants" are just scripts in another container. In a language tag, I see very little benefit to having a tag like "el-grek-mono" instead of an "el-mono" or an "en-Latn-Lipa" over an "en-Lipa". >> Not to mention: if script variations aren't registered in 15924, where >> will they come from? What rules will be applied to their registration? >> Why does anyone think ietf-languages will be a good arbiter of said >> variations? > > ISO 15924 hasn't scored too highly for us so far. Addressing what a > script variant really is will need some discussion, of course. Yes, and from hard experience I don't believe that ietf-languages is a better solution. A few email exchanges with ISO 15924 folks does not indicate utter failure and other ideas might be useful before creating new language subtag fauna. > > Remember that ISO 15924 isn't our standard to control. It's coming from > TC46. "Controlling a standard" implies some measure of responsibility. In this case, RFC 4646 strives to *avoid* making up its own rules and "working around" the underlying ISO standards. In fact, registration of language tags has a long and dubious history in this regard: many existing registrations have later been repented when (for example) ISO 639 took action at a later date. The most likely possibility is that ISO 15924, by its definition, does not define all of the orthographic variations that are needed in language tags. While you (or I) might not like the 15924 JAC's decisions, I must admit that they have a certain logic. However, I also note that modifying language tags is probably not the best method of overcoming this deficiency. There is precedent for creating a project such as an ISO 15924 Part 2 "Codes for the representation of scripts and script variations". Such a project, if it shared a codespace with 15924-1, would be a more methodical and consistent way to register the values you seek. > > In the meantime, please send me the form to request 7000 language > variants or extensions (since both are registered by language). Extensions are NOT AT ALL associated with particular languages (unless the RFC that defines them says they are). Variants are NOT required to be associated with specific languages, although there is stern resistance by some to "generic" variants. If you were to propose (say) 'phonipa' as a variant with no Prefix field, I would probably support it. And the form is in RFC 4646. > > I would encourage folks to think about how the language tag can be made > productive. If every possible language tag in effect has to be > registered, it will push many tags underground and the x- extension > space will become far more popular than we might want it to be. Not really. Hardly anyone uses the registered stuff. And the x- private use space was made productive with subtags to facilitate those with specialized needs. I *hope* that more people can derive use from tags such as en-x-ipa-glasgow (oh, hey! there's your tag :-) ). > I, for > example, have to deal with emerging writing systems and storing data in > them for archival purposes long before such writing systems are well > established (in some cases), if every such instance needs to be > registered RFC4646 will be seen as a bottle kneck to be worked around > rather than in collaboration with. > Your use case is explicitly what private-use subtags are for: idiosyncratic or specialized requirements. Yes, every subtag you want to use has to be registered if you want it to be non-private-use. But previously you needed to registered entire tags (including every variation you wanted), so 4646 greatly improves your situation. But I would start with really trying harder with 15924, followed by looking at creating a registry for "scripts and script variations", preferably within TC 46. Nothing that does not confront us today will prevent us from adding "script variants" in the future if they are truly necessary. But I don't see that as strictly necessary yet. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 13:59:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOeRQ-0006Sx-J6; Sat, 16 Sep 2006 13:59:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOeRO-0006Rq-Pl for ltru@lists.ietf.org; Sat, 16 Sep 2006 13:58:58 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOeRM-0007S9-Pm for ltru@lists.ietf.org; Sat, 16 Sep 2006 13:58:58 -0400 Received: from [10.72.72.7] (snvvpn1-10-72-72-c7.corp.yahoo.com [10.72.72.7]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8GHwofd048534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Sep 2006 10:58:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=qiV9hhMPBfXqyQkmkws02OYf5zBXrMANA8PTgJ8hPQm03vukniSN7JiHaLdjH0up Message-ID: <450C3B5A.4060008@yahoo-inc.com> Date: Sat, 16 Sep 2006 10:58:50 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Re: UTF-8 References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> <6.0.0.20.2.20060916114849.081056e0@localhost> In-Reply-To: <6.0.0.20.2.20060916114849.081056e0@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > I'm sure the logistic problems with IANA can be sorted out > (e.g. using attachments). > Or sending the form in escaped ASCII and telling IANA to unescape it. > As for using compression, this can be done mostly transparently. > browsers tell servers what encodings they support, e.g. like so: > Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 > The server can be configured to send the appropriatly encoded > version of the file. > I don't see any reason for us to dabble in transfer encodings! Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 14:04:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOeWG-0000VE-V0; Sat, 16 Sep 2006 14:04:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOeWF-0000Ux-OR for ltru@ietf.org; Sat, 16 Sep 2006 14:03:59 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOeWE-0008Un-Dj for ltru@ietf.org; Sat, 16 Sep 2006 14:03:59 -0400 Received: from [10.72.72.7] (snvvpn1-10-72-72-c7.corp.yahoo.com [10.72.72.7]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8GI3pJu048724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Sep 2006 11:03:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=RnzJ2l+StXfnd2RUdeNp5XKtz22ribYnv7XpXvlzKkFsI1w0dlIpEeNONxThe8DB Message-ID: <450C3C87.8030904@yahoo-inc.com> Date: Sat, 16 Sep 2006 11:03:51 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: UTF-8 References: <008801c6d9b3$da4b9e40$6401a8c0@DGBP7M81> In-Reply-To: <008801c6d9b3$da4b9e40$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > 1. whether the Registry format should be changed to XML (or another > file format) I oppose this. > 2. whether the Registry should use UTF-8 directly instead of hex NCRs I support this, but could live without it. > > BTW, I keep seeing references to the Registry being in "modified > record-jar." Would someone please refresh my memory: What is "modified" > about the Registry's format as compared to "standard" record-jar? Since there ain't no such beast as "standard record-jar", nothing. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 14:46:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOfAw-0000MA-5q; Sat, 16 Sep 2006 14:46:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOfAv-0000KU-2H for ltru@ietf.org; Sat, 16 Sep 2006 14:46:01 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOfAs-0007fp-Lp for ltru@ietf.org; Sat, 16 Sep 2006 14:46:01 -0400 Received: by nf-out-0910.google.com with SMTP id n15so2732465nfc for ; Sat, 16 Sep 2006 11:45:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=sEhqCabaDzZQukUIrERar4b1ajYHLhDk+I+l6US1wOeMfS6l5DHwV49Wf2hl4/hzHl7hoJR+sN8T5PCSbx3eHKRNXGXzeMOij+d3jdMdkzCGa7S6fBPRdlLCja7AgN8zcCvI01SKSM7QsgdqqiuR+ZJfkzzmr7nbdhLTV4UisXo= Received: by 10.49.19.18 with SMTP id w18mr14934850nfi; Sat, 16 Sep 2006 11:45:57 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Sat, 16 Sep 2006 11:45:56 -0700 (PDT) Message-ID: <30b660a20609161145h47e63289n1f9a96b9fc682c34@mail.gmail.com> Date: Sat, 16 Sep 2006 12:45:56 -0600 From: "Mark Davis" To: "Martin Hosken" Subject: Re: [Ltru] Re: script tag for IPA In-Reply-To: <450C18FA.3090500@sil.org> MIME-Version: 1.0 References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <6.0.0.20.2.20060915154910.06e040b0@localhost> <450AC979.3050203@yahoo-inc.com> <450B60D4.1040401@sil.org> <004301c6d947$bef6f980$6401a8c0@DGBP7M81> <450C18FA.3090500@sil.org> X-Google-Sender-Auth: 0fde1edc4aaab308 X-Spam-Score: 0.8 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1371573764==" Errors-To: ltru-bounces@ietf.org --===============1371573764== Content-Type: multipart/alternative; boundary="----=_Part_152506_22782305.1158432356885" ------=_Part_152506_22782305.1158432356885 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I generally agree with Addison's comments. A couple of further items. 1. Procedurally, the possibility of getting an IPA script variant is not zero. It was proposed, there was very little discussion, and dismissed without a lot of discussion (I'm just an observer). So if a more reasoned document is presented there could be different results. Unlike other cases, it is not up to one person capriciousness. 2. I think the private use codes (for script, etc) are misunderstood. If an authority designates a code as private use code, that means that it is recognized as a valid code, but that authority doesn't attach a meaning to it, and never will. It does not mean that nobody else can attach a meaning to it -- if that were the case it would be completely pointless to have private use codes. For example, the Unicode Consortium defines a meaning for Qaai ( http://www.unicode.org/reports/tr24/). Any application conformant to the Unicode Standard must interpret Qaai as applied with that meaning. It also attaches meaning to certain private use tags in CLDR (LDML), notably for some region codes: QO Outlying Oceania QU European Union ZZ Unknown or Invalid TerritoryBut it only takes part of the range: "The private use codes from XA..XZ will never be used by CLDR, and are thus safe for use for other purposes by applications using CLDR data". It would be possible for RFC4646bis to define a range of private use codes that it will use. This would need to be very carefully done, and we might decide that it is not appropriate, but it is certainly a possibility. Mark ------=_Part_152506_22782305.1158432356885 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I generally agree with Addison's comments. A couple of further items.

1. Procedurally, the possibility of getting an IPA script variant is not zero. It was proposed, there was very little discussion, and dismissed without a lot of discussion (I'm just an observer). So if a more reasoned document is presented there could be different results. Unlike other cases, it is not up to one person capriciousness.

2. I think the private use codes (for script, etc) are misunderstood. If an authority designates a code as private use code, that means that it is recognized as a valid code, but that authority doesn't attach a meaning to it, and never will.

It does not mean that nobody else can attach a meaning to it -- if that were the case it would be completely pointless to have private use codes. For example, the Unicode Consortium defines a meaning for Qaai ( http://www.unicode.org/reports/tr24/). Any application conformant to the Unicode Standard must interpret Qaai as applied with that meaning. It also attaches meaning to certain private use tags in CLDR (LDML), notably for some region codes:
QO Outlying Oceania
QU European Union
ZZ Unknown or Invalid Territory
But it only takes part of the range: "The private use codes from XA..XZ will never be used by CLDR, and are thus safe for use for other purposes by applications using CLDR data".

It would be possible for RFC4646bis to define a range of private use codes that it will use. This would need to be very carefully done, and we might decide that it is not appropriate, but it is certainly a possibility.

Mark
------=_Part_152506_22782305.1158432356885-- --===============1371573764== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1371573764==-- From ltru-bounces@ietf.org Sat Sep 16 14:47:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOfBv-0000dY-Nw; Sat, 16 Sep 2006 14:47:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOfBu-0000dS-3p for ltru@ietf.org; Sat, 16 Sep 2006 14:47:02 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOfBq-0007v1-TD for ltru@ietf.org; Sat, 16 Sep 2006 14:47:02 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GOfBq-0004Bl-Jn; Sat, 16 Sep 2006 14:46:58 -0400 Date: Sat, 16 Sep 2006 14:46:58 -0400 To: Doug Ewell Subject: Re: [Ltru] IPA and other transcriptions (was: Re: script tag for IPA) Message-ID: <20060916184658.GC25175@ccil.org> References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <6.0.0.20.2.20060915154910.06e040b0@localhost> <450AC979.3050203@yahoo-inc.com> <450B60D4.1040401@sil.org> <004301c6d947$bef6f980$6401a8c0@DGBP7M81> <450C18FA.3090500@sil.org> <009601c6d9b5$cf9defa0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009601c6d9b5$cf9defa0$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > In what way -- other than the actual repertoire of characters used -- do > IPA and other phonetic and phonemic notation systems, differ from those? I would say in that IPA and its rivals are not orthographies; that is, the meaning of [f] in IPA is standardized, but the choice of when to use it in the representation of some language depends on the acuity of the transcriber. Per contra, it is very clear when "f" is to be written in the various romanizations of Japanese, whether the sound represented is IPA [f] or not. And I do agree that IPA (and rival) sound transcription systems are a very different matter from mere variants in transcription like pinyin vs. Wade-Giles or Hepburn vs. kunrei shiki. -- Even a refrigerator can conform to the XML John Cowan Infoset, as long as it has a door sticker cowan@ccil.org saying "No information items inside". http://www.ccil.org/~cowan --Eve Maler _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 15:17:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOff2-0004nN-NC; Sat, 16 Sep 2006 15:17:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOff0-0004mf-OP for ltru@ietf.org; Sat, 16 Sep 2006 15:17:06 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOfew-0005Kp-D4 for ltru@ietf.org; Sat, 16 Sep 2006 15:17:06 -0400 Received: from [10.72.76.233] (snvvpn2-10-72-76-c233.corp.yahoo.com [10.72.76.233]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8GJGxV8047704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 16 Sep 2006 12:17:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=IvHZGFxK9qIu5a2H3jkTJzGGLwbENG2f5fSHO1EDxLPgJTOJd7LE2DaOu/Z9p/tZ Message-ID: <450C4DAB.4040102@yahoo-inc.com> Date: Sat, 16 Sep 2006 12:16:59 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "'LTRU Working Group'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ltru] [OT] record-jar format draft... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug gently mentioned the question of "standard" vs. "modified" record-jar format. Which reminds me that I really should finish off the record-jar informational RFC some time. Today I updated my draft-00 of it and posted it on my personal web site. I welcome comments (it needs some more tweaking). I note that this version is closer to the LTRU format than previously. For those interested, discussion is at record-jar@yahoogroups.com and the documents are at: http://www.inter-locale.com/ID/draft-phillips-record-jar-00.txt http://www.inter-locale.com/ID/draft-phillips-record-jar-00.html http://www.inter-locale.com/ID/draft-phillips-record-jar-00.xml Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 19:04:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOjD7-0006qM-Qz; Sat, 16 Sep 2006 19:04:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOjD6-0006qA-Cz for ltru@ietf.org; Sat, 16 Sep 2006 19:04:32 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOjD2-0002MJ-24 for ltru@ietf.org; Sat, 16 Sep 2006 19:04:32 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.628.4; Sat, 16 Sep 2006 16:04:27 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Sat, 16 Sep 2006 16:04:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: script tag for IPA Date: Sat, 16 Sep 2006 16:04:15 -0700 Message-ID: In-Reply-To: <20060915121152.GC25144@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: script tag for IPA Thread-Index: AcbYwCqkdm9RzGBGRMK4cXn8EoIYGABI1r/A From: Peter Constable To: X-OriginalArrivalTime: 16 Sep 2006 23:04:27.0327 (UTC) FILETIME=[7578F4F0:01C6D9E4] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org So, if we're entertaining ABNF changes, what about this? langtag =3D language ["-" script ["-" scriptvar] ... scriptvar =3D 4alpha=20 where scriptvar subtags are defined per a registration and *not* = interpreted in terms of ISO 15924. That's a limited change in syntax and gives 456,976 possible = script-variant subtags (should be more than plenty for transcriptions = and transliterations). Peter > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: Friday, September 15, 2006 5:12 AM > To: Martin Duerst > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: script tag for IPA >=20 > Martin Duerst scripsit: >=20 > > The solution proposed by Martin Hosken seems to make quite a bit > > of sense to me. I only see two problems: > > - This would need a change to the RFC 4646 ABNF. This is serious. >=20 > Not a big one; basically we would need to allow multiple script = subtags, > just as we allow multiple variant subtags today. Order is enough to > tell which is primary and which are secondary, so we need play no = tricks > with case; and there is no ambiguity, because currently a well-formed > tag can have only one non-initial 4-letter subtag. >=20 > I'm not necessarily saying I approve of this, just saying it's not a > big deal technically. Changing the ABNF at all is indeed a big deal = in > terms of our commitments, however, so the sooner we decide to do this > or not do this the better. >=20 > -- > John Cowan cowan@ccil.org ccil.org/~cowan > Dievas dave dantis; Dievas duos duonos --Lithuanian proverb > Deus dedit dentes; deus dabit panem --Latin version = thereof > Deity donated dentition; > deity'll donate doughnuts --English version by = Muke > Tever > God gave gums; God'll give granary --Version by Mat = McVeagh >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 19:10:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOjIj-0000US-Kq; Sat, 16 Sep 2006 19:10:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOjIi-0000UN-Ej for ltru@ietf.org; Sat, 16 Sep 2006 19:10:20 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOjIh-0003A5-6x for ltru@ietf.org; Sat, 16 Sep 2006 19:10:20 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Sat, 16 Sep 2006 16:10:18 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Sat, 16 Sep 2006 16:10:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: script tag for IPA Date: Sat, 16 Sep 2006 16:10:02 -0700 Message-ID: In-Reply-To: <450B60D4.1040401@sil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: script tag for IPA Thread-Index: AcbZN5pNyTP7KWNJQaKhALbFwbVcbQArWk1g From: Peter Constable To: X-OriginalArrivalTime: 16 Sep 2006 23:10:14.0195 (UTC) FILETIME=[4438D030:01C6D9E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1407803419==" Errors-To: ltru-bounces@ietf.org --===============1407803419== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBNYXJ0aW4gSG9za2VuIFttYWlsdG86bWFydGluX2hvc2tlbkBzaWwub3JnXQ0KDQoN Cj4gSG93IGRvIEkgdGFnIHRleHQgaW4gdGhlIElQQSBzY3JpcHQgdGhhdCBjYW4gYmUgaW4gYW55 DQo+IGxhbmd1YWdlPyANCg0KSnVzdCB0byBjbGFyaWZ5OiBJUEEgY2FuIGJlIHVzZWQgdG8gdHJh bnNjcmliZSBhbnkgbGFuZ3VhZ2UsIGJ1dCBhbnkgaW5zdGFuY2Ugb2YgSVBBIHRyYW5zY3JpcHRp b24gaXMgaW4gKnNvbWUqIHBhcnRpY3VsYXIgbGFuZ3VhZ2UuDQoNCg0KDQpQZXRlciBDb25zdGFi bGUNCg== --===============1407803419== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1407803419==-- From ltru-bounces@ietf.org Sat Sep 16 19:28:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOjZv-0006pH-B6; Sat, 16 Sep 2006 19:28:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOjZt-0006np-KM for ltru@lists.ietf.org; Sat, 16 Sep 2006 19:28:05 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOjZr-0006gm-3p for ltru@lists.ietf.org; Sat, 16 Sep 2006 19:28:05 -0400 Received: by nf-out-0910.google.com with SMTP id n15so2764947nfc for ; Sat, 16 Sep 2006 16:28:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=fMS9qmBsNxr+aXeYzVXu13407P1rLk6ucjSzY3huUkd1ErgkNHTEkgCAEJ6w/h1+oIRXPSV261LNJI7HpDNVnpOUZ6KU226aCKDCnk3MWOkBtV0mTch6YT68gKo1iqBzQvcufJdLKt2yGXhj2W7vpi/EoQFG9HDQSWi1PWI2POc= Received: by 10.48.48.15 with SMTP id v15mr15176032nfv; Sat, 16 Sep 2006 16:28:01 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Sat, 16 Sep 2006 16:28:01 -0700 (PDT) Message-ID: <30b660a20609161628t22ab3c4flc81ea92f40800a09@mail.gmail.com> Date: Sat, 16 Sep 2006 16:28:01 -0700 From: "Mark Davis" To: "Martin Duerst" Subject: Re: [Ltru] Re: Test suite for language tags? In-Reply-To: <6.0.0.20.2.20060901024806.109a6d90@localhost> MIME-Version: 1.0 References: <20060801203351.GA8854@sources.org> <20060802072709.GA17404@nic.fr> <44D21ACD.4040707@yahoo-inc.com> <20060804165720.GA24037@sources.org> <44D4AC42.79E0@xyzzy.claranet.de> <20060830093000.GA31895@nic.fr> <44F6313D.2070000@yahoo-inc.com> <6.0.0.20.2.20060831201004.101ab8d0@localhost> <44F6EF0E.20602@yahoo-inc.com> <6.0.0.20.2.20060901024806.109a6d90@localhost> X-Google-Sender-Auth: 00c82b82f04de333 X-Spam-Score: 0.3 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1034181887==" Errors-To: ltru-bounces@ietf.org --===============1034181887== Content-Type: multipart/alternative; boundary="----=_Part_154598_25343641.1158449281699" ------=_Part_154598_25343641.1158449281699 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline BTW, I had updated my regex to the final spec for 4646. Here is a single Perl or Java regex that does most of the parse: Regex: ((?: [a-z A-Z]{2,3} (?: [-] [a-z A-Z]{3} ){0,3} | [a-z A-Z]{4,8} ))(?: [-] ((?: [a-z A-Z]{4} )) )?(?: [-] ((?: [a-z A-Z]{2} | [0-9]{3} )) )?(?: [-] ((?: (?: [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) (?: [-] (?: [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) )* )) )?(?: [-] ((?: (?: [a-w y-z A-W Y-Z] (?: [-] [a-z A-Z 0-9]{2,8} )+ ) (?: [-] (?: [a-w y-z A-W Y-Z] (?: [-] [a-z A-Z 0-9]{2,8} )+ ) )* )) )?(?: [-] ((?: [xX] (?: [-] [a-z A-Z 0-9]{1,8} )+ )) )?| ( (?i) art [-] lojban| cel [-] gaulish| en [-] (?: boont | GB [-] oed | scouse )| i [-] (?: ami | bnn | default | enochian | hak | klingon | lux | mingo | navajo | pwn | tao | tay | tsu )| no [-] (?: bok | nyn)| sgn [-] (?: BE [-] fr | BE [-] nl | CH [-] de)| zh [-] (?: cmn | zh [-] cmn [-] Hans | cmn [-] Hant | gan | guoyu | hakka | min | min [-] nan | wuu | xiang | yue))| ((?: [xX] (?: [-] [a-z A-Z 0-9]{1,8} )+ )) It checks for the grandfathered tags, since otherwise too much cruft sneaks in. You can't check in regex that there are only single instances of each singleton extension. (In retrospect we could have allowed multiple singletons: we could have accepted en-a-bcdef-ghijk-b-123-a-lmnop as equivalent to the canonical form en-a-bcdef-ghijk-lmnop-b-123, but that's water under the bridge at this point.) Of course, I didn't put this together by hand. The table used to build it is much more readable, at http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagRegex.txt and a test file that includes strings mentioned on this list is at: http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagTest.txt Mark ------=_Part_154598_25343641.1158449281699 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline QlRXLCBJIGhhZCB1cGRhdGVkIG15IHJlZ2V4IHRvIHRoZSBmaW5hbCBzcGVjIGZvciA0NjQ2LiBI ZXJlIGlzIGEgc2luZ2xlIFBlcmwgb3IgSmF2YSByZWdleCB0aGF0IGRvZXMgbW9zdCBvZiB0aGUg cGFyc2U6PGJyPjxicj5SZWdleDogKCg/OiBbYS16IEEtWl17MiwzfSAoPzogWy1dIFthLXogQS1a XXszfSApezAsM30gfCBbYS16IEEtWl17NCw4fSApKSg/OiBbLV0gKCg/OiBbYS16IEEtWl17NH0g KSkgKT8oPzogWy1dICgoPzogW2EteiBBLVpdezJ9IHwgWzAtOV17M30gKSkgKT8oPzogWy1dICgo PzogKD86IFswLTldIFthLXogQS1aIDAtOV17M30gfCBbYS16IEEtWiAwLTldezUsOH0gKSAoPzog Wy1dICg/OiBbMC05XSBbYS16IEEtWiAwLTldezN9IHwgW2EteiBBLVogMC05XXs1LDh9ICkgKSog KSkgKT8oPzogWy1dICgoPzogKD86IFthLXcgeS16IEEtVyBZLVpdICg/OiBbLV0gW2EteiBBLVog MC05XXsyLDh9ICkrICkgKD86IFstXSAoPzogW2EtdyB5LXogQS1XIFktWl0gKD86IFstXSBbYS16 IEEtWiAwLTldezIsOH0gKSsgKSApKiApKSApPyg/OiBbLV0gKCg/OiBbeFhdICg/OiBbLV0gW2Et eiBBLVogMC05XXsxLDh9ICkrICkpICk/fCAoICg/aSkgYXJ0IFstXSBsb2piYW58IGNlbCBbLV0g Z2F1bGlzaHwgZW4gWy1dICg/OiBib29udCB8IEdCIFstXSBvZWQgfCBzY291c2UgKXwgaSBbLV0g KD86IGFtaSB8IGJubiB8IGRlZmF1bHQgfCBlbm9jaGlhbiB8IGhhayB8IGtsaW5nb24gfCBsdXgg fCBtaW5nbyB8IG5hdmFqbyB8IHB3biB8IHRhbyB8IHRheSB8IHRzdSApfCBubyBbLV0gKD86IGJv ayB8IG55bil8IHNnbiBbLV0gKD86IEJFIFstXSBmciB8IEJFIFstXSBubCB8IENIIFstXSBkZSl8 IHpoIFstXSAoPzogY21uIHwgemggWy1dIGNtbiBbLV0gSGFucyB8IGNtbiBbLV0gSGFudCB8IGdh biB8IGd1b3l1IHwgaGFra2EgfCBtaW4gfCBtaW4gWy1dIG5hbiB8IHd1dSB8IHhpYW5nIHwgeXVl KSl8ICgoPzogW3hYXSAoPzogWy1dIFthLXogQS1aIDAtOV17MSw4fSApKyApKQo8YnI+PGJyPkl0 IGNoZWNrcyBmb3IgdGhlIGdyYW5kZmF0aGVyZWQgdGFncywgc2luY2Ugb3RoZXJ3aXNlIHRvbyBt dWNoIGNydWZ0IHNuZWFrcyBpbi4gWW91IGNhbid0IGNoZWNrIGluIHJlZ2V4IHRoYXQgdGhlcmUg YXJlIG9ubHkgc2luZ2xlIGluc3RhbmNlcyBvZiBlYWNoIHNpbmdsZXRvbiBleHRlbnNpb24uIChJ biByZXRyb3NwZWN0IHdlIGNvdWxkIGhhdmUgYWxsb3dlZCBtdWx0aXBsZSBzaW5nbGV0b25zOiB3 ZSBjb3VsZCBoYXZlIGFjY2VwdGVkIGVuLWEtYmNkZWYtZ2hpamstYi0xMjMKPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OiBib2xkOyI+LWEtbG1ub3A8L3NwYW4+IGFzIGVxdWl2YWxlbnQgdG8gdGhl IGNhbm9uaWNhbCBmb3JtIGVuLWEtYmNkZWYtZ2hpamstPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OiBib2xkOyI+bG1ub3A8L3NwYW4+LWItMTIzLCBidXQgdGhhdCdzIHdhdGVyIHVuZGVyIHRoZSBi cmlkZ2UgYXQgdGhpcyBwb2ludC4pIE9mIGNvdXJzZSwgSSBkaWRuJ3QgcHV0IHRoaXMgdG9nZXRo ZXIgYnkgaGFuZC4gVGhlIHRhYmxlIHVzZWQgdG8gYnVpbGQgaXQgaXMgbXVjaCBtb3JlIHJlYWRh YmxlLCBhdAo8YnI+PGJyPjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OiA0MHB4OyI+PGEgaHJlZj0i aHR0cDovL3VuaWNvZGUub3JnL2NsZHIvZGF0YS90b29scy9qYXZhL29yZy91bmljb2RlL2NsZHIv dXRpbC9kYXRhL2xhbmd0YWdSZWdleC50eHQiPmh0dHA6Ly91bmljb2RlLm9yZy9jbGRyL2RhdGEv dG9vbHMvamF2YS9vcmcvdW5pY29kZS9jbGRyL3V0aWwvZGF0YS9sYW5ndGFnUmVnZXgudHh0PC9h Pgo8YnI+PC9kaXY+PGJyPmFuZCBhIHRlc3QgZmlsZSB0aGF0IGluY2x1ZGVzIHN0cmluZ3MgbWVu dGlvbmVkIG9uIHRoaXMgbGlzdCBpcyBhdDo8YnI+PGJyPjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 OiA0MHB4OyI+PGEgaHJlZj0iaHR0cDovL3VuaWNvZGUub3JnL2NsZHIvZGF0YS90b29scy9qYXZh L29yZy91bmljb2RlL2NsZHIvdXRpbC9kYXRhL2xhbmd0YWdUZXN0LnR4dCI+aHR0cDovL3VuaWNv ZGUub3JnL2NsZHIvZGF0YS90b29scy9qYXZhL29yZy91bmljb2RlL2NsZHIvdXRpbC9kYXRhL2xh bmd0YWdUZXN0LnR4dAo8L2E+PGJyPjwvZGl2Pk1hcms8YnI+Cg== ------=_Part_154598_25343641.1158449281699-- --===============1034181887== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1034181887==-- From ltru-bounces@ietf.org Sat Sep 16 19:28:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOja8-0006wW-Fi; Sat, 16 Sep 2006 19:28:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOja7-0006u0-4b for ltru@ietf.org; Sat, 16 Sep 2006 19:28:19 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOja5-0006hI-SB for ltru@ietf.org; Sat, 16 Sep 2006 19:28:19 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060916232813.BFAV28624.mta11.adelphia.net@DGBP7M81>; Sat, 16 Sep 2006 19:28:13 -0400 Message-ID: <00ac01c6d9e7$c7e90dd0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <6.0.0.20.2.20060915154910.06e040b0@localhost> <450AC979.3050203@yahoo-inc.com> <450B60D4.1040401@sil.org> <004301c6d947$bef6f980$6401a8c0@DGBP7M81> <450C18FA.3090500@sil.org> <009601c6d9b5$cf9defa0$6401a8c0@DGBP7M81> <20060916184658.GC25175@ccil.org> Subject: Re: [Ltru] IPA and other transcriptions (was: Re: script tag for IPA) Date: Sat, 16 Sep 2006 16:28:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >> In what way -- other than the actual repertoire of characters used -- >> do IPA and other phonetic and phonemic notation systems, differ from >> those? > > I would say in that IPA and its rivals are not orthographies; that is, > the meaning of [f] in IPA is standardized, but the choice of when to > use it in the representation of some language depends on the acuity of > the transcriber. Per contra, it is very clear when "f" is to be > written in the various romanizations of Japanese, whether the sound > represented is IPA [f] or not. I agree that there are differences in the details of their use, but what I was getting at was that both are alternative "ways of writing" language (note that incredibly vague phrase). Pinyin (et al.) is not a "normal" way of writing Chinese (et al.); it is a special application for learners and other non-native readers of the language. (This is different from, say, Serbian in Cyrillic/Latin, where native readers might use either script.) Likewise, IPA (et al.) is not a "normal" way of writing English (et al.); it is a special application for linguists and others who need to represent the exact (or nearly exact) pronunciation of the language. > And I do agree that IPA (and rival) sound transcription systems are a > very different matter from mere variants in transcription like pinyin > vs. Wade-Giles or Hepburn vs. kunrei shiki. OK, well, that wasn't the way I saw it, but since almost everyone on this list probably has more linguistic training than I do, perhaps I should back off on this. Maybe the thing to consider in 4646bis is whether we should remove the extension mechanism altogether. If transcription and transliteration systems aren't a good application for extensions, I really don't know what is, and nobody else has come forward with a "favorite" potential application for them. The examples in 4646 are all contrived. Extensions have never been valid in real-world language tags (since none are defined), so they could be removed without breaking anything, and doing so would simplify parsers. "Deprecating" them, of course, would be completely pointless. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 19:34:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOjg1-00009A-Hd; Sat, 16 Sep 2006 19:34:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOjg0-000095-11 for ltru@ietf.org; Sat, 16 Sep 2006 19:34:24 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOjfy-0006u3-QD for ltru@ietf.org; Sat, 16 Sep 2006 19:34:24 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060916233422.WJGB27224.mta10.adelphia.net@DGBP7M81>; Sat, 16 Sep 2006 19:34:22 -0400 Message-ID: <00ae01c6d9e8$a3deb740$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 16 Sep 2006 16:34:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >> I'm sure the logistic problems with IANA can be sorted out (e.g. >> using attachments). > > Or sending the form in escaped ASCII and telling IANA to unescape it. At the very least, there would have to be an AUTH48-like period where we could review the end product and make corrections before it was publicly posted on IANA's site. > I don't see any reason for us to dabble in transfer encodings! No, please. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 16 23:00:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOmtA-0005Dt-3O; Sat, 16 Sep 2006 23:00:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOmt7-0005D0-LL for ltru@lists.ietf.org; Sat, 16 Sep 2006 23:00:10 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOmt2-0006OG-Mw for ltru@lists.ietf.org; Sat, 16 Sep 2006 23:00:09 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8H30005016314 for ; Sun, 17 Sep 2006 12:00:01 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 369e_9bdd6ac4_45f8_11db_9c3c_0014221fa3c9; Sun, 17 Sep 2006 11:59:59 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:41800) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 17 Sep 2006 12:00:05 +0900 Message-Id: <6.0.0.20.2.20060917115535.0899d670@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 17 Sep 2006 11:56:56 +0900 To: "Mark Davis" From: Martin Duerst Subject: Re: [Ltru] Re: Test suite for language tags? In-Reply-To: <30b660a20609161628t22ab3c4flc81ea92f40800a09@mail.gmail.co m> References: <20060801203351.GA8854@sources.org> <20060802072709.GA17404@nic.fr> <44D21ACD.4040707@yahoo-inc.com> <20060804165720.GA24037@sources.org> <44D4AC42.79E0@xyzzy.claranet.de> <20060830093000.GA31895@nic.fr> <44F6313D.2070000@yahoo-inc.com> <6.0.0.20.2.20060831201004.101ab8d0@localhost> <44F6EF0E.20602@yahoo-inc.com> <6.0.0.20.2.20060901024806.109a6d90@localhost> <30b660a20609161628t22ab3c4flc81ea92f40800a09@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org There's a mistake in the regex, from the underlying langtagRegex.txt, that allows zh-zh-cmn-Hans. Regards, Martin. At 08:28 06/09/17, Mark Davis wrote: >BTW, I had updated my regex to the final spec for 4646. Here is a single Perl or Java regex that does most of the parse: > >Regex: ((?: [a-z A-Z]{2,3} (?: [-] [a-z A-Z]{3} ){0,3} | [a-z A-Z]{4,8} ))(?: [-] ((?: [a-z A-Z]{4} )) )?(?: [-] ((?: [a-z A-Z]{2} | [0-9]{3} )) )?(?: [-] ((?: (?: [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) (?: [-] (?: [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) )* )) )?(?: [-] ((?: (?: [a-w y-z A-W Y-Z] (?: [-] [a-z A-Z 0-9]{2,8} )+ ) (?: [-] (?: [a-w y-z A-W Y-Z] (?: [-] [a-z A-Z 0-9]{2,8} )+ ) )* )) )?(?: [-] ((?: [xX] (?: [-] [a-z A-Z 0-9]{1,8} )+ )) )?| ( (?i) art [-] lojban| cel [-] gaulish| en [-] (?: boont | GB [-] oed | scouse )| i [-] (?: ami | bnn | default | enochian | hak | klingon | lux | mingo | navajo | pwn | tao | tay | tsu )| no [-] (?: bok | nyn)| sgn [-] (?: BE [-] fr | BE [-] nl | CH [-] de)| zh [-] (?: cmn | zh [-] cmn [-] Hans | cmn [-] Hant | gan | guoyu | hakka | min | min [-] nan | wuu | xiang | yue))| ((?: [xX] (?: [-] [a-z A-Z 0-9]{1,8} )+ )) > >It checks for the grandfathered tags, since otherwise too much cruft sneaks in. You can't check in regex that there are only single instances of each singleton extension. (In retrospect we could have allowed multiple singletons: we could have accepted en-a-bcdef-ghijk-b-123 -a-lmnop as equivalent to the canonical form en-a-bcdef-ghijk-lmnop-b-123, but that's water under the bridge at this point.) Of course, I didn't put this together by hand. The table used to build it is much more readable, at > >http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagRegex.txt > >and a test file that includes strings mentioned on this list is at: > >http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagTest.txt >Mark #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 01:29:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOpDN-0001pt-85; Sun, 17 Sep 2006 01:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOpDM-0001po-Cl for ltru@ietf.org; Sun, 17 Sep 2006 01:29:12 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOpDJ-00017N-WC for ltru@ietf.org; Sun, 17 Sep 2006 01:29:12 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060917052909.NJGP10468.mta9.adelphia.net@DGBP7M81> for ; Sun, 17 Sep 2006 01:29:09 -0400 Message-ID: <010201c6da1a$3405ad70$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 16 Sep 2006 22:29:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Subject: [Ltru] Process for creating 4646bis Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Here is my first pass at describing the process for generating the RFC 4646bis Language Subtag Registry. This is not necessarily the exact wording that will appear in RFC 4645bis, but parts of it may end up there with little or no change. This needs to be evaluated by the WG on at least two levels: * the process itself * the way the process is described (logic, clarity, ambiguity, mechanics, etc.) 1. Starting point The existing Registry serves as the starting point for the new Registry. RFC 4645bis will include a reference (probably normative) to RFC 4645 for those who wish to trace the path all the way back to the ISO and UN standards and RFC 3066 tag registry. The new inputs to the Registry are the ISO/FDIS 639-3 online code tables. This includes the code set dated 2006-04-21 and the macrolanguage mappings dated 2005-06-14, which are currently (2006-09-16) available on the ISO 639-3 home page. Peter has said there are changes in the FDIS document not reflected in these files, and more changes will be coming, but I am using these files because they are the most up-to-date information available to me. 2. Language subtags modified The existing Registry includes 489 primary language subtags, including some for "language collections" not included in 639-3. In cases where the reference name(s) in 639-3 for these languages differ(s) from the Description fields in the Registry, the new names are added to the existing Registry entry, after all existing descriptions. For example, the subtag "gd" currently has the descriptions "Gaelic" and "Scottish Gaelic"; the new description "Gaelic (Scots)" from 639-3 will be added. This includes inverted forms of existing names, such as "Frisian, Northern". This also includes language names that include a country name, to differentiate them from other languages of the same name associated with a different country. For example, the subtag "bas" currently has the description "Basa"; to this would be added "Basa (Cameroon)" from 639-3. The new subtag "bzw" would have the single description "Basa (Nigeria)". Reference names in the 639-3 files that contain the strings "(generic)" or "(specific)" are changed to "(macrolanguage)" and the empty string, respectively, in accordance with Peter's statement on September 12 that the FDIS already includes this change. The single exception is "Zande (specific)" (zne), which is left unchanged because there is also a 639-3 code element "Zande" (znd) and neither of these is a macrolanguage. No existing Description fields are changed or deleted. 3. New subtags added All 639-3 code elements not in the LSR are added as primary language subtags if they are not included under a 639-3 macrolanguage, or as extended language subtags if they are (with the macrolanguage as Prefix). This is consistent with John Cowan's description of the process, which was generally approved by the list. As a special case, all 639-3 languages with the words "Sign Language" in their name are added as extlangs, with "sgn" as the Prefix. This is the same as if 639-3 had listed them under a macrolanguage "sgn". (The entry "sgn", being a collection code, is not present in 639-3 at all.) All subtags added to the Registry are added in alphabetical order within their type, with the 2-letter language subtags appearing before the 3-letter subtags. IANA previously added two 3-letter subtags, "anp" and "frr", in the section for 2-letter subtags, which is allowed by RFC 4646 but may surprise some readers. No attempt is made here to change this. 4. Grandfathered and redundant tags As a consequence of adding these new subtags, the following grandfathered tags are deprecated, with the indicated tag specified as Preferred-Value: i-ami -> ami i-bnn -> bnn i-pwn -> pwn i-tao -> tao i-tay -> tay i-tsu -> tsu sgn-CH-de -> sgn-sgg zh-hakka -> zh-hak zh-min -> (no Preferred-Value, just deprecated) zh-min-nan -> zh-nan zh-xiang -> zh-hns Each of these grandfathered tags has a Comment field indicating the ISO 639-3 code element (for example, "replaced by ISO code ami"). This duplicates the Preferred-Value information and is not strictly necessary, but is added for consistency with other grandfathered tags. This comment is also added to the tag "zh-guoyu", which is already deprecated in favor of another grandfathered tag, "zh-cmn" (which will now be redundant; see below). The following grandfathered tags are now fully composable and are moved to redundant: zh-cmn zh-cmn-Hans zh-cmn-Hant zh-gan zh-wuu zh-yue The following redundant sign-language tags are deprecated (requiring a change in the RFC 4646 rules, which currently disallow this). sgn-BR -> sgn-bzs sgn-CO > sgn-csn sgn-DE > sgn-gsg sgn-DK > sgn-dsl sgn-ES > sgn-ssp sgn-FR > sgn-fsl sgn-GB > sgn-bfi sgn-GR > sgn-gss sgn-IE > sgn-isg sgn-IT > sgn-ise sgn-JP > sgn-jsl sgn-MX > sgn-mfs sgn-NI > sgn-ncs sgn-NL > sgn-dse sgn-NO > sgn-nsl sgn-PT > sgn-psr sgn-SE > sgn-swl sgn-US > sgn-ase sgn-ZA > sgn-sfs No change is made to the Description field for these tags, so (for example) "sgn-US" will still have the description "American Sign Language". This is to avoid unintended changes of scope. 5. Availability A prototype 4646bis Registry built using these rules, with an arbitrary File-Date (and Added date for all new subtags) of 2007-01-01, is available at: http://users.adelphia.net/~dewell/lstreg-4646bis.txt (640,265 bytes) http://users.adelphia.net/~dewell/lstreg-4646bis.zip (78,943 bytes, PKZip format) Please use these files as necessary to evaluate the process. Please do not distribute them or build anything for release based on them; remember that the rules are not final. They will not be changed until a revised version of this process is posted to LTRU, so please download them only once per revision. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 01:41:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOpPT-0006dS-17; Sun, 17 Sep 2006 01:41:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOpPS-0006cw-1X for ltru@ietf.org; Sun, 17 Sep 2006 01:41:42 -0400 Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOpPM-0002dD-Mp for ltru@ietf.org; Sun, 17 Sep 2006 01:41:42 -0400 Received: from spam.cs.tut.fi (spam-eth1.lintula [10.11.18.2]) by mail.cs.tut.fi (Postfix) with ESMTP id D6BB9A21B for ; Sun, 17 Sep 2006 08:41:31 +0300 (EEST) Received: from mail.cs.tut.fi ([130.230.4.42]) by spam.cs.tut.fi (spam.cs.tut.fi [10.11.18.2]) (amavisd-new, port 10024) with ESMTP id 22642-08 for ; Sun, 17 Sep 2006 08:41:31 +0300 (EEST) Received: from mustatilhi.cs.tut.fi (mustatilhi.cs.tut.fi [130.230.4.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id 936B29D3E for ; Sun, 17 Sep 2006 08:41:31 +0300 (EEST) Date: Sun, 17 Sep 2006 08:41:31 +0300 (EEST) From: "Jukka K. Korpela" To: ltru@ietf.org Subject: RE: [Ltru] Re: script tag for IPA In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: amavisd-new at cs.tut.fi X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sat, 16 Sep 2006, Peter Constable wrote: >> From: Martin Hosken [mailto:martin_hosken@sil.org] > >> How do I tag text in the IPA script that can be in any >> language? > > Just to clarify: IPA can be used to transcribe any language, but any > instance of IPA transcription is in *some* particular language. Normally so, but the particular language may be unknown; this however is no different from a case where you have, say, text in Latin letters and you do not know its language (yet). Moreover, it is possible to use IPA to describe words that appear the same (in pronunciation) in different languages, in which case we would probably use "mul" if we had to tag the text. So there are situations where there the language tagging is not obvious, but this may happen for any script, not just IPA. -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 02:19:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOpzo-0002ym-HL; Sun, 17 Sep 2006 02:19:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOpzn-0002xq-9d for ltru@ietf.org; Sun, 17 Sep 2006 02:19:15 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOpzl-0006CM-2A for ltru@ietf.org; Sun, 17 Sep 2006 02:19:15 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GOpzk-0002d7-M4 for ltru@ietf.org; Sun, 17 Sep 2006 02:19:12 -0400 Date: Sun, 17 Sep 2006 02:19:12 -0400 To: ltru@ietf.org Message-ID: <20060917061912.GB26073@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Ltru] RFC 4646 production "grandfathered" considered harmful X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Section 2.2.9 of RFC 4646 says: An implementation that claims to check for well-formed language tags MUST: o Check that the tag and all of its subtags, including extension and private use subtags, conform to the ABNF OR that the tag is on the list of grandfathered tags. o Check that singleton subtags that identify extensions do not repeat. For example, the tag "en-a-xx-b-yy-a-zz" is not well- formed. (I have emphasized the word OR in the first bullet point.) Unfortunately, this wording allows too much. For example, the invalid tag "ra-bb-it" matches the "grandfathered" rule in the ABNF. Therefore it winds up being well-formed even though it cannot be analyzed as a sequence of subtags and is not on the grandfathered list either. To avoid this, we can take one of two actions: 1) Remove the "grandfathered" production in the ABNF altogether, and use the "OR" in the conformance clause to allow the irregular grandfathered tags (that is, those which don't match the "langtag" or "privateuse" productions) to be well-formed. The danger here is that people will implement the ABNF only, and the grandfathered tags will become outright unusable rather than merely discouraged. 2) Add an explicit "irregular" production in place of the "grandfathered" production which explicitly enumerates the 17 irregular grandfathered tags, thus: 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" It is safe to enumerate this list explicitly, as it can neither grow nor shrink. It's true that all the tags except "i-default" can become deprecated, but that makes no difference to well-formed processors. The other grandfathered tags in the registry are all well-formed already and do not need to be in this list. In this case the conformance clause can be simplified by omitting the second part of the "OR". I favor choice 2. -- John Cowan cowan@ccil.org "You need a change: try Canada" "You need a change: try China" --fortune cookies opened by a couple that I know _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 03:02:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOqfk-0001ah-1c; Sun, 17 Sep 2006 03:02:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOqfg-0001ZX-Ik for ltru@ietf.org; Sun, 17 Sep 2006 03:02:32 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOqfe-0003VT-PI for ltru@ietf.org; Sun, 17 Sep 2006 03:02:32 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8H72Q0X001470 for ; Sun, 17 Sep 2006 16:02:27 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 36f0_79fba76e_461a_11db_97cc_0014221fa3c9; Sun, 17 Sep 2006 16:02:25 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:58821) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 17 Sep 2006 16:02:32 +0900 Message-Id: <6.0.0.20.2.20060917154346.08a01070@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 17 Sep 2006 15:45:11 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: UTF-8 In-Reply-To: <00ae01c6d9e8$a3deb740$6401a8c0@DGBP7M81> References: <00ae01c6d9e8$a3deb740$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 08:34 06/09/17, Doug Ewell wrote: >Addison Phillips wrote: > >>> I'm sure the logistic problems with IANA can be sorted out (e.g. using attachments). >> >> Or sending the form in escaped ASCII and telling IANA to unescape it. > > Agreed. >At the very least, there would have to be an AUTH48-like period where we could review the end product and make corrections before it was publicly posted on IANA's site. We got that last time round, so I don't see a problem here. >> I don't see any reason for us to dabble in transfer encodings! > >No, please. Of course we shouldn't invent new transfer encodings. But suggesting to IANA that they also offer the file as compressed over HTTP should be okay, or not? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 03:02:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOqfl-0001bl-Cy; Sun, 17 Sep 2006 03:02:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOqfj-0001aY-Om for ltru@lists.ietf.org; Sun, 17 Sep 2006 03:02:35 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOqfe-0003VX-PI for ltru@lists.ietf.org; Sun, 17 Sep 2006 03:02:35 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/seFrom ltru-bounces@ietf.org Sun Sep 17 03:02:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOqfk-0001ah-1c; Sun, 17 Sep 2006 03:02:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOqfg-0001ZX-Ik for ltru@ietf.org; Sun, 17 Sep 2006 03:02:32 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOqfe-0003VT-PI for ltru@ietf.org; Sun, 17 Sep 2006 03:02:32 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8H72Q0X001470 for ; Sun, 17 Sep 2006 16:02:27 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 36f0_79fba76e_461a_11db_97cc_0014221fa3c9; Sun, 17 Sep 2006 16:02:25 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:58821) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 17 Sep 2006 16:02:32 +0900 Message-Id: <6.0.0.20.2.20060917154346.08a01070@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 17 Sep 2006 15:45:11 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: UTF-8 In-Reply-To: <00ae01c6d9e8$a3deb740$6401a8c0@DGBP7M81> References: <00ae01c6d9e8$a3deb740$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 08:34 06/09/17, Doug Ewell wrote: >Addison Phillips wrote: > >>> I'm sure the logistic problems with IANA can be sorted out (e.g. using attachments). >> >> Or sending the form in escaped ASCII and telling IANA to unescape it. > > Agreed. >At the very least, there would have to be an AUTH48-like period where we could review the end product and make corrections before it was publicly posted on IANA's site. We got that last time round, so I don't see a problem here. >> I don't see any reason for us to dabble in transfer encodings! > >No, please. Of course we shouldn't invent new transfer encodings. But suggesting to IANA that they also offer the file as compressed over HTTP should be okay, or not? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 03:02:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOqfl-0001bl-Cy; Sun, 17 Sep 2006 03:02:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOqfj-0001aY-Om for ltru@lists.ietf.org; Sun, 17 Sep 2006 03:02:35 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOqfe-0003VX-PI for ltru@lists.ietf.org; Sun, 17 Sep 2006 03:02:35 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8H72S4D001474 for ; Sun, 17 Sep 2006 16:02:29 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 3702_7b236e88_461a_11db_8a97_0014221fa3c9; Sun, 17 Sep 2006 16:02:27 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:58821) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 17 Sep 2006 16:02:33 +0900 Message-Id: <6.0.0.20.2.20060917154808.08a12880@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 17 Sep 2006 15:59:12 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: UTF-8 In-Reply-To: <450BD347.9EA@xyzzy.claranet.de> References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> <6.0.0.20.2.20060916114849.081056e0@localhost> <450BD347.9EA@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 19:34 06/09/16, Frank Ellermann wrote: >Martin Duerst wrote: > > [UTF-8 registry] >>> I'm opposed. >> It would be good to know why. > >ftp://ftp.iana.org/assignments/language-subtag-registry > >I've no clue what FTP clients would do with something like >that. Just save the file. If it's transferred as text, things may go wrong for an EBCDIC system. If transferred as binary, it will still be UTF-8. >John's "net-UTF-8" draft isn't ready, and I had some >troubles to understand his last published version. That isn't very relevant, except that it suggests normalization to NFC, which I assume we would do anyway, and which is already an issue in the case of NCRs. >Another issue are fonts, for RFC 4646 there were proposals >to restrict the registry to Latn. Bad idea. Any average browser installation has way wider coverage. >Fortunately that was >dropped, because the problem doen't exist with US-ASCII >plus NCRs. > >> something like Bokmål is just plain annoying. > >At least we know what this is. Bokm$B%F!&(Bl is less clear - >raw UTF-8 displayed as Latin-1, http://purl.net/net/ucode/E5 Well, and then interpreted as Shift-JIS in the case of my mailer :-(. Our spec as well as the HTTP headers will say that it's UTF-8. That should be enough. People who are okay to see garbage will be as satisfied with Bokmå as they are with Bokm$B%F!&(Bl, or any other weird rendering, but people who like to see the real thing will be best served by UTF-8. >> I'm sure the logistic problems with IANA can be sorted >> out (e.g. using attachments). > >Yes. I doubt that there is any logistic problem for mail >submissions. Only for the bulk update, the fattest I-D in >the history of the Internet using B64, they'd shoot us. We could define a process experiment. As it is only for an I-D, not for an RFC, that should work. I have seen non-ASCII stuff in I-Ds, but checks may be a bit more strict nowadays. >We could try QP, and silently send them Doug's original >data (as mail) in addition to the I-D. If 'them' is IANA, that might work. If 'them' is the Internet-Drafts Editor, that'd not make sense. >We've no clear idea which tools will exist for the 4646 >format in six months, how they do their updates (http or >ftp), and what local conversions they use. Doug alrcret) with SMTP id k8H72S4D001474 for ; Sun, 17 Sep 2006 16:02:29 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 3702_7b236e88_461a_11db_8a97_0014221fa3c9; Sun, 17 Sep 2006 16:02:27 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:58821) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 17 Sep 2006 16:02:33 +0900 Message-Id: <6.0.0.20.2.20060917154808.08a12880@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 17 Sep 2006 15:59:12 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: UTF-8 In-Reply-To: <450BD347.9EA@xyzzy.claranet.de> References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> <6.0.0.20.2.20060916114849.081056e0@localhost> <450BD347.9EA@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 19:34 06/09/16, Frank Ellermann wrote: >Martin Duerst wrote: > > [UTF-8 registry] >>> I'm opposed. >> It would be good to know why. > >ftp://ftp.iana.org/assignments/language-subtag-registry > >I've no clue what FTP clients would do with something like >that. Just save the file. If it's transferred as text, things may go wrong for an EBCDIC system. If transferred as binary, it will still be UTF-8. >John's "net-UTF-8" draft isn't ready, and I had some >troubles to understand his last published version. That isn't very relevant, except that it suggests normalization to NFC, which I assume we would do anyway, and which is already an issue in the case of NCRs. >Another issue are fonts, for RFC 4646 there were proposals >to restrict the registry to Latn. Bad idea. Any average browser installation has way wider coverage. >Fortunately that was >dropped, because the problem doen't exist with US-ASCII >plus NCRs. > >> something like Bokmål is just plain annoying. > >At least we know what this is. Bokm$B%F!&(Bl is less clear - >raw UTF-8 displayed as Latin-1, http://purl.net/net/ucode/E5 Well, and then interpreted as Shift-JIS in the case of my mailer :-(. Our spec as well as the HTTP headers will say that it's UTF-8. That should be enough. People who are okay to see garbage will be as satisfied with Bokmå as they are with Bokm$B%F!&(Bl, or any other weird rendering, but people who like to see the real thing will be best served by UTF-8. >> I'm sure the logistic problems with IANA can be sorted >> out (e.g. using attachments). > >Yes. I doubt that there is any logistic problem for mail >submissions. Only for the bulk update, the fattest I-D in >the history of the Internet using B64, they'd shoot us. We could define a process experiment. As it is only for an I-D, not for an RFC, that should work. I have seen non-ASCII stuff in I-Ds, but checks may be a bit more strict nowadays. >We could try QP, and silently send them Doug's original >data (as mail) in addition to the I-D. If 'them' is IANA, that might work. If 'them' is the Internet-Drafts Editor, that'd not make sense. >We've no clear idea which tools will exist for the 4646 >format in six months, how they do their updates (http or >ftp), and what local conversions they use. Doug already >proposed that an UTF-8 version might have to keep the >& convention, that could be confusing. Yes. I'd agree that '&#x' sequences might need escaping, but I don't expect any of these. Simple & would be okay unescaped, it would trigger an error in strictly implemented RFC 4646 software, the same way as UTF-8, and would not cause any interpretation problems. >And we'd have >to decide if a signature is required, another change of >the record-jar ABNF. Yes. No signature, please. >> compression, this can be done mostly transparently. >> browsers tell servers what encodings they support, e.g. >> like so: >> Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 > >ACK, I forgot this, my favourite browser uses HTTP/1.0 ;-) > >An explicit gzip variant could still make sense for ftp >and HTTP/1.0 (?) Yes. >We can add some "IANA might consider to >offer" blurb in the IANA considerations, but IMO we can't >tell them how to run their servers. Agreed. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru eady >proposed that an UTF-8 version might have to keep the >& convention, that could be confusing. Yes. I'd agree that '&#x' sequences might need escaping, but I don't expect any of these. Simple & would be okay unescaped, it would trigger an error in strictly implemented RFC 4646 software, the same way as UTF-8, and would not cause any interpretation problems. >And we'd have >to decide if a signature is required, another change of >the record-jar ABNF. Yes. No signature, please. >> compression, this can be done mostly transparently. >> browsers tell servers what encodings they support, e.g. >> like so: >> Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 > >ACK, I forgot this, my favourite browser uses HTTP/1.0 ;-) > >An explicit gzip variant could still make sense for ftp >and HTTP/1.0 (?) Yes. >We can add some "IANA might consider to >offer" blurb in the IANA considerations, but IMO we can't >tell them how to run their servers. Agreed. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 06:13:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOtec-0007LG-VG; Sun, 17 Sep 2006 06:13:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOteb-0007KJ-Jq for ltru@lists.ietf.org; Sun, 17 Sep 2006 06:13:37 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOteX-0005iQ-V4 for ltru@lists.ietf.org; Sun, 17 Sep 2006 06:13:37 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GOteC-0003ah-0F for ltru@lists.ietf.org; Sun, 17 Sep 2006 12:13:12 +0200 Received: from pd9fba9c1.dip0.t-ipconnect.de ([217.251.169.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Sep 2006 12:13:11 +0200 Received: from nobody by pd9fba9c1.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Sep 2006 12:13:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 17 Sep 2006 12:06:51 +0200 Organization: Lines: 120 Message-ID: <450D1E3B.7064@xyzzy.claranet.de> References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> <6.0.0.20.2.20060916114849.081056e0@localhost> <450BD347.9EA@xyzzy.claranet.de> <6.0.0.20.2.20060917154808.08a12880@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba9c1.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: >> I've no clue what FTP clients would do with something >> like that. > Just save the file. If it's transferred as text, things > may go wrong for an EBCDIC system. If transferred as > binary, it will still be UTF-8. The old FTP server on my box needed an option "-cp none" for "raw mode", otherwise it would try to "get it right" with weird results (cp 858 to cp 1252 or vice versa, my number of UTF-8 plain text files is still *_zero_*) >> John's "net-UTF-8" draft isn't ready, and I had some >> troubles to understand his last published version. > That isn't very relevant, except that it suggests > normalization to NFC, which I assume we would do anyway, > and which is already an issue in the case of NCRs. Let's please just use whatever the source standards use, garbage in garbage out (drawing the line at "invalid"). In an unrelated (SASLprep) attempt to check how bad this is some weeks ago my conclusion was "bad enough" after I found 418 combining characters. The last thing we need in a 4646bis is a fixed Unicode version (or convoluted prose why that's unnecessary). >> for RFC 4646 there were proposals to restrict the >> registry to Latn. > Bad idea. Any average browser installation has way > wider coverage. Or way less, almost certainly not "all Latn", the next least common denominator after Latin-1 could be MES-1. Fighting with obscure glyph lists is another issue to be solved by the source standards, not 4646bis. [UTF-8 Bokmål mangled to Latin-1] > Well, and then interpreted as Shift-JIS in the case of > my mailer :-(. Folks will discuss registry entries on the review list, with any MUA they have. With NCRs as abstract objects they'd be at least sure _what_ they discuss. >> for the bulk update, the fattest I-D in the history of >> the Internet using B64, they'd shoot us. > We could define a process experiment. As it is only for > an I-D, not for an RFC, that should work. Yes, and as long as the AD is okay with it we might get away without 3933 for this detail - after a bounce from the secretary ("too long" or "non-ASCII") until they believe it. > I have seen non-ASCII stuff in I-Ds, but checks may be > a bit more strict nowadays. I'm not sure that it was always UTF-8, in one case where it was windows-1252 the I-D wasn't published. If they're ready to accept any non-ASCII it ought to include UTF-8, otherwise they've to fix it anyway sooner or later. >> We could try QP, and silently send them Doug's original >> data (as mail) in addition to the I-D. > If 'them' is IANA, that might work. If 'them' is the > Internet-Drafts Editor, that'd not make sense. IANA. I'd guess that the "I-D-editor" is in essence a mailbot - with a human operator trying to fix some wild and wonderful submissions where that mailbot isn't sure. QP UTF-8 would be only a trick to get the draft published. IANA could take the decoded attached file - or roll their own QP I-D to registry decoder, it's no rocket science. >> keep the & convention, that could be confusing. > Yes. I'd agree that '&#x' sequences might need escaping, > but I don't expect any of these. Simple & would be okay > unescaped, it would trigger an error in strictly implemented > RFC 4646 software, the same way as UTF-8, and would not > cause any interpretation problems. Assuming that we go that way (I still don't like it) we could "forbid" &#x strings for backwards compatibility. With "forbid" s/&#x//g. Or "forbid" s/&#x/u+/g, because it probably is precisely the same problem in the sources. To justify such manipulations in 4646bis the WG should adopt the record-jar I-D as work item (informational RFC). I could contribute 212 lines LTRU record-jar to XML as an example (in the long version allowing to check all subtag references with the W3C validator). >> we'd have to decide if a signature is required, another >> change of the record-jar ABNF. > Yes. No signature, please. I could in theory note UTF-8 as an "extended attribute" of the file. At some point I've to start that anyway, my local "if it's not ASCII it's cp 858" rule does not help for published files, nobody knows what cp 858 is. With or without signature, UTF-8 will fail miserably in some constellations. With a signature you could say that it's not the fault of the registry. Without signature, I don't see where a misinterpretation as UTF-16 fails, some "line too long" error ? Maybe a dummy encoding="UTF-8" XML wrapper could help, one element with a fixed xml:space="preserve" attribute (?) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 06:24:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOtos-0002Y8-E7; Sun, 17 Sep 2006 06:24:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOtoq-0002WI-Qe for ltru@lists.ietf.org; Sun, 17 Sep 2006 06:24:12 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOtop-0007tH-Hj for ltru@lists.ietf.org; Sun, 17 Sep 2006 06:24:12 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GOtog-0005dz-MF for ltru@lists.ietf.org; Sun, 17 Sep 2006 12:24:02 +0200 Received: from pd9fba9c1.dip0.t-ipconnect.de ([217.251.169.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Sep 2006 12:24:02 +0200 Received: from nobody by pd9fba9c1.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Sep 2006 12:24:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 17 Sep 2006 12:23:30 +0200 Organization: Lines: 10 Message-ID: <450D2222.5F8@xyzzy.claranet.de> References: <20060917061912.GB26073@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba9c1.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] Re: RFC 4646 production "grandfathered" considered harmful X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Add an explicit "irregular" production Interesting idea. Maybe add "zh-hakka" as "almost irregular", or let's _define_ hakka as deprecated zh variant. For zh-cmn I hope 4646bis will solve a "missing cmn" issue as side effect. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 07:25:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOuld-0007JV-Rr; Sun, 17 Sep 2006 07:24:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOuld-0007JP-4i for ltru@lists.ietf.org; Sun, 17 Sep 2006 07:24:57 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOula-0000J8-M4 for ltru@lists.ietf.org; Sun, 17 Sep 2006 07:24:57 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GOulO-0002xn-8g for ltru@lists.ietf.org; Sun, 17 Sep 2006 13:24:42 +0200 Received: from pd9fba9c1.dip0.t-ipconnect.de ([217.251.169.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Sep 2006 13:24:42 +0200 Received: from nobody by pd9fba9c1.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Sep 2006 13:24:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 17 Sep 2006 13:22:49 +0200 Organization: Lines: 60 Message-ID: <450D3009.505C@xyzzy.claranet.de> References: <010201c6da1a$3405ad70$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba9c1.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.6 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Subject: [Ltru] Re: Process for creating 4646bis Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > RFC 4645bis will include a reference (probably normative) to > RFC 4645 for those who wish to trace the path all the way > back to the ISO and UN standards and RFC 3066 tag registry. Okay, we have already a reference to RFC 4645 in 4646bis-01pre, but you need it also. > The new inputs to the Registry are the ISO/FDIS 639-3 online > code tables. For the drafts before Last Call. For the registry it should be the then existing ISO 639-3:2007. > the subtag "gd" currently has the descriptions "Gaelic" and > "Scottish Gaelic"; the new description "Gaelic (Scots)" from > 639-3 will be added. As Randy and Debbie wanted it. You had convinced me that replacing xxxx by xxxx (yyyy) instead of adding it might be okay, but for a first draft any consistent rule goes, we know that it's an open issue. > No existing Description fields are changed or deleted. ACK, that's KISS, please note it explicitly. > extended language subtags if they are (with the macrolanguage > as Prefix). This is consistent with John Cowan's description > of the process, which was generally approved by the list. It's another open issue, compare For the first draft it's fine, let's look at the output, and then decide if we really like this "macrolanguage" cruft. The job of 4646bis is to define language tags, not to sanction the POVs of its sources, for that folks should read these sources, not the registry. > zh-hakka -> zh-hak Resulting in i-hak -> zh-hakka -> zh-hak (JFTR, we have to eat our dog food) > zh-min -> (no Preferred-Value, just deprecated) That has to be justified explicitly in prose, as an exception. > http://users.adelphia.net/~dewell/lstreg-4646bis.txt Thanks, quick check with the W3C validator (8167 records): One known yi-latn (lower case L) error, anything else okay. My old registry validator does not yet support extlang XREFs, otherwise it's happy: | 8167 (sub)tags in 41651 lines, 804 xrefs okay Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 07:46:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOv6A-0006MO-5A; Sun, 17 Sep 2006 07:46:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOv68-0006Ls-OS for ltru@lists.ietf.org; Sun, 17 Sep 2006 07:46:08 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOv66-00067s-En for ltru@lists.ietf.org; Sun, 17 Sep 2006 07:46:08 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GOv5k-0008Gh-QU for ltru@lists.ietf.org; Sun, 17 Sep 2006 13:45:44 +0200 Received: from pd9fba9c1.dip0.t-ipconnect.de ([217.251.169.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Sep 2006 13:45:44 +0200 Received: from nobody by pd9fba9c1.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Sep 2006 13:45:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 17 Sep 2006 13:44:50 +0200 Organization: Lines: 27 Message-ID: <450D3532.59A9@xyzzy.claranet.de> References: <008801c6d9b3$da4b9e40$6401a8c0@DGBP7M81> <450C3C87.8030904@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba9c1.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ltru] record-jar (was: UTF-8) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >> whether the Registry format should be changed to XML (or >> another file format) > I oppose this. Me too, but for UTF-8 I'd be tempted to change my mind. It's interesting as derived format, to check all subtags in Doug's first registry I needed less than a minute: Most of it spent with "upload XML to W3C validator", followed by "download TXT from Doug's Web space", seconds to convert it to XML, and wait for the validator's result (= "yi-latn is no valid XML" :-) >> What is "modified" about the Registry's format as compared >> to "standard" record-jar? > Since there ain't no such beast as "standard record-jar", > nothing. Does the original record-jar allow comments introduced by % ? For "original" = as published in the [record-jar] reference. Looking into your updated draft, you have %% comment, and some backslash magic, that's "modified" wrt RFC 4646. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 07:51:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOvBb-0007Qw-MW; Sun, 17 Sep 2006 07:51:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOvBa-0007QP-F1 for ltru@lists.ietf.org; Sun, 17 Sep 2006 07:51:46 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOvBZ-0006bq-6J for ltru@lists.ietf.org; Sun, 17 Sep 2006 07:51:46 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GOvBN-0001a0-8t for ltru@lists.ietf.org; Sun, 17 Sep 2006 13:51:33 +0200 Received: from pd9fba9c1.dip0.t-ipconnect.de ([217.251.169.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Sep 2006 13:51:33 +0200 Received: from nobody by pd9fba9c1.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Sep 2006 13:51:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 17 Sep 2006 13:50:41 +0200 Organization: Lines: 13 Message-ID: <450D3691.75B0@xyzzy.claranet.de> References: <008201c6d9b2$ebfd2600$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba9c1.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] Re: DOCTYPE ltru X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: >> with XML ID _latn is not _Latn. > It's capitalized that way because it was registered that way > under RFC 3066. Could we add this oddity as another exception (like zh-min) to 4645bis, or is it more straight forward if I try to update it directly using the language list ? Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 08:11:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOvUa-0007GS-03; Sun, 17 Sep 2006 08:11:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOvUY-0007FZ-RJ for ltru@lists.ietf.org; Sun, 17 Sep 2006 08:11:22 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOvUX-0007jI-Ho for ltru@lists.ietf.org; Sun, 17 Sep 2006 08:11:22 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GOvUI-0006wS-R9 for ltru@lists.ietf.org; Sun, 17 Sep 2006 14:11:06 +0200 Received: from pd9fba9c1.dip0.t-ipconnect.de ([217.251.169.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Sep 2006 14:11:06 +0200 Received: from nobody by pd9fba9c1.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Sep 2006 14:11:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 17 Sep 2006 13:56:43 +0200 Organization: Lines: 7 Message-ID: <450D37FB.1D9A@xyzzy.claranet.de> References: <20060915121152.GC25144@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba9c1.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Ltru] Re: script tag for IPA X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > That's a limited change in syntax Breaking two out of two LTRU "tools" I have... I could live with it, but it would break _all_ RFC 4646 tools worldwide :-( _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 10:37:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOxlv-0000SE-VN; Sun, 17 Sep 2006 10:37:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOxlu-0000RX-Nc for ltru@lists.ietf.org; Sun, 17 Sep 2006 10:37:26 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOxlo-0006Ea-KI for ltru@lists.ietf.org; Sun, 17 Sep 2006 10:37:26 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id EFBC1240814; Sun, 17 Sep 2006 16:37:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 95AF311969; Sun, 17 Sep 2006 16:34:45 +0200 (CEST) Date: Sun, 17 Sep 2006 16:34:45 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20060917143445.GA10307@sources.org> References: <450B2F27.FD7@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: <450B2F27.FD7@xyzzy.claranet.de> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Cc: ltru@lists.ietf.org Subject: [Ltru] Re: DOCTYPE ltru X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Sep 16, 2006 at 12:54:31AM +0200, Frank Ellermann wrote a message of 90 lines which said: > For the XML fans, below you find a possible DTD for the > ltru2xml script posted yesterday. I've never tried that > before, probably it's clumsy. The W3C validator accepts > it for a converted registry. A few remarks (only on details, I won't get in the dispute elements-vs-attributes): 1) May be we should use the same vocabulary as the RFC 4646. For instance, you use "date" when the RFC uses (except for the element) "added". Or you use "tag" when the RFC uses subtag or tag, depending on the type. 2) Even with DTDs, I believe it is possible to factor common terms like "description", which is the same for every record. 3) I do not see Preferred-value in your schema? I attached my own attempt, written in RelaxNG, and a translated registry. --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ltru.rnc" # RelaxNG schema for the "language tag" registry specified in RFC 4646 # and available at http://www.iana.org/assignments/language-subtag-registry # Not standard in any way, just an individual proposal # Stephane Bortzmeyer # TODO: add Schematron rules for constraints such as "Records that # contain a 'Preferred-Value' field MUST also have a 'Deprecated' # field. " This specific constraint does not really require # Schematron, but others may. start = registry registry = element registry {date & languages & scripts & regions & variants & redundants & grandfathereds} # TODO: extensions date = element date {xsd:date} languages = language* language = element language {subtag & common & suppress-script?} scripts = script* script = element script {subtag & common} regions = region* region = element region {subtag & common} variants = variant* variant = element variant {subtag & common & prefix*} # "Records of type 'variant' # MAY have more than one field of type" 'Prefix'. grandfathereds = grandfathered* grandfathered = element grandfathered {tag & common} redundants = redundant* redundant = element redundant {tag & common} common = added & descriptions & deprecated? & preferred-value? added = element added {xsd:date} suppress-script = element suppress-script {text} descriptions = description+ # Each record MUST contain the following fields description = element description {text} subtag = element subtag {text} tag = element tag {text} prefix = element prefix {text} deprecated = element deprecated {xsd:date} preferred-value = element preferred-value {text} --zYM0uCDKw75PZbzx Content-Type: application/octet-stream Content-Disposition: attachment; filename="language-tag-registry.xml.gz" Content-Transfer-Encoding: base64 H4sICKJaDUUCA2xhbmd1YWdlLXRhZy1yZWdpc3RyeS54bWwAzJ1rbxw3soa/n18xQICsDESJ nbWzG8QIIMnyZWXJOhnZOck3djfVzWk22eZlRq1ff9iSvLGt0YwervrgALtIYnP6Ld6KVcVi vc+drJUPbvj1eSWC/PXHx49/2n38z93HT5//cPUHz7UwdRR1+jcfiyDqX4V4/sPNvz4XVSWr 8UfPdp883n3y0/Mfrv/keSV96VQflDW/7p0Ll7722Z88/+HfX/2vNQAFBSjaRlwqYb5C8bHv nfR+9/rPfj0YnB4//eWfbhFGUmGW0odbomzGOMcj6lQrhPFbOvxWBIM73FJhWtjbjgJ0jXCq 3NLXw9Ao3FdDRXGitkZ6iTps+jUwaZv9Pe209TCmTvOLMBzvSbF1TMdGeEw9lcR70d0e0q9R 96WpsSxLvHnXrLTNEAOFGDrhxBQb95JKcildIdRCGEV6XFD9vy980yp0BBRU6+5LLVz005wB RU2libpOC2kaYRoqjBrVJxp9hSG8Fh1SWEWHV1FX3N44mzEMXkWmFlpNoIkKC0U5U4WEZkRB z4B9J4NlEFS571tvtu+DHHVXUjV0IILQt0T5/D8+CC1NOZG4VKMdNLJsJJqdssEYorPO2Sn6 Sxf8gXVelWzFl3TFHziJTLeSrveDSznOwsMPZ8RTG13ZzOZaLG8ZNJ//xztdXTWyZmOzzz63 peX4wbvOv6/bbf7q5gFZ8gFZJkMEYVDb7nep/RSzX1Fd9yLZdNNIQtXYK+m6SRRqRRfAC7WU jdqwIl8021ocC12p5fYD4qy5DpKg/lDz/cWlNXXbbHMlkiERqCySzvLhCqlVqekqSnq7/W52 bCvpzGznydNnf999tKXj6Tct7ji1GA9NrafZaZIeoIe+l06YMMVpLuk5OO/XaaAvzTEflJ7G 2JIBj10yhCeSJXJ3+WOUE0hyTk+RU+nu4VHnBInOacTzZdQCnd3n1Id9qcxEZ+b5AouymGYt nlOd8lI4uz00lyUKNd1fuuSbTTI9zsHw7Il1oRkPopdOrdkgm9G4TelDJlZNN/wbN80OqCt6 3gupN3oZ89KGkISdrW25WRhsfIiEMM2GrKm98SoKdzte+yCiRCzKIskStsmSmjksC7Xtj4W5 mGBMGrqBXovoUYiyoZb2a1k4udrS17ER7is9MF8rU22b/BdyiR2hxmJBnEquQYho4HnoyKbF PokWaAJeZipsjq7ctJgdOGn1FOd3Q9XF62judSeSJQy+hHOdNPcxbTsuyyXe0U7eCsFuhFD4 XDfJhNBq/Mxs5+o/jBj/QujZXrwYvTA3zN7ewMxme97bdOCNLR4huSosVzXepk+zKJTMHiUU zFD0dvBNXbDpppp5rsomps3/B7r1Uy0er9gr8RFhmP9XK4SeNG8qNnE0avKmlOkj1da8jKzO 0kPmTRAThWdU5CutDSrEgEZ/9f/FtFpQff0v0QuaZbSgWuIPVVWKXYgslrgjS96R1f8BSCvw PYZ19fbtMDajy6OlB8iRNTVSRC1dG0eqjUPcYF++Wtdgsww0CnaUjrDhdlbJF01Wa5tsloMe c0fiUrTNBJk8rcaSaCG0Vv6WIvz6rsRMdoy0NG/nqOmk2yJIasN3jcGjZ4yotl2XHZkKe6yt xRvYSRbKax3vbWRZX63HEL7pFASJWAs4ekq1SzwdHevEiue2GNqJAatsVzfqkmBoeggmhaGm MAg1zfh/Gy9kV9iYjuSNl4xvZbiURWqW/myKwLaucSzZVOi40vTofqu6scMbo0M3bW7p5TVt 4LLVBos7plxOkQ+tLV7d26/OrcViBDwiYfTep3G9dMQ7rRC7RyKkD7F1u+S6ZTlNn7sa3yZo UQs/TCFLg2VxvklG3zS3sJ3C4lh24HctRihldZ9kjByTu9MZS2FI/++2CHOshw4LQ3Xl8ej3 aXgJ3FmMoisx1VZ0fPmL0ExxzdT5nKUwxZgELkiYSB0M+KGLu8fTreOBu3eG2qYnIro4wZgY apueWLeSY6hotm/b7ttvLg6f/aKnEIzetpxUspBafje7yl/ZYPpd/f3spvkUktObmRPZb3+W k6METI3H0EJDyNAj50UM5abZeallN02ajjHZS/1kMNb5dgqhbK5QUwjjcvfc3MaNe+7q76fc c0usT5diYTdpidSgQWFoM+A3G6ps5EpsfJiy+e9PBmEWU7iXtoSdeVeWKrlRs53e+jB78uzx 40cb5D51dinNeHr84xehyShbGmh/t1DFCuk0S4PA75ztpshLtw4LooZtq+GdG/BBYqk1+c57 uSWH57oJym3scYr3uDuKTW9eTuO6Frez/FykY9YrLKxGvmdPj95TO9Fjjp4uj9Pom60vOXIy 7/uAx8SFWMdpHI6PNBz131GOuS0TiOKoTvtNyGB3f7OdMCW6e3bUzPotbs+0zOoyNa2uOjuN ZeUiHhQ/UbkHt8JXL2YQbrUmtP8QI+OpTp8L41unULKMLzGIq5SBsShf4Uw2UzVI53vJ3YXr xxxzwW4Bfc3npZ7CCPI0pjyXrrC7dyQ0b4biqYimuX29c7vF9uNlbIdHhgaf59ouxRRerNcZ ksiJdK3v8Mrt7DSS0KNw3liDXBVPz7h5OuP0FKet/0iT1HUx1WnrXYbKoLoCvxlebX9NlNXZ gJdAaOxNyEa6ScafWjvzZALiJEe/xDMgq2kcIL/ii6FRk+zDQO2ps2QYbAvgpzbYzgzUVDmT Otbb7jjGRliSGg/JQrVkKQZqo5w1Qm2vsoErPgaF63DVbjTvJ6g+Gah1chZd27GSUEHjma2F tvUU+46e9Wc+uVRTeFQBF2MbL31mO9f/eOPH5Fr/aArBXMaKmEZhB49na83N2INIEvASDqzg cKCH09kKeYphwD1oFHXNItXh71XdxE0ZgO+HNQ02y0A12vvWCTVRrk+km+m9q+IEEddIH4S+ vywkOlyX1JD4IKcJVS3p6fpByWDuU/03Sxqq5j9YLfpvv7l4efALGv8VtSh/F1pbVnlzRTvz u9X2fIJRvaCW3P801k+x2IaHefD2EA/8Bjo5f1gXCxTHuKRr7M8xibjeXNLxdoPNMvD6oor6 rJfUM/4z6inSvgQu2LpX8t4KXLJ1r7TsElTg4pF7VfpGx/pR4QoMVbIu5IblOTaQrKfnnJnC 2d09P5Y6KGc778ZozyOG2GQwN6yJa2xGwa/m95RBbzNFy0kfWlFBC1VovKW0ZG++BX6Qs6dr az7GMYft09c8Q+TRxeuw4mxPB8EWAk5XvClP+d1srLa7U4rvZ0+fpcZPbucebQbGeSV7fVJt MnNIXcnJLDoBeRtcBvdHLAW98hSu5zg9TKwTLmCQoM7HqmY6S+/hK/LUqZVARrXAYfs9H+KW otP7otDsYMOBy73QpPnzZbZCiZhAJfrgrmp1ZCJi/2VvJeC1fCEqXAYVvpQshOKUEkrLNlNN FUJjPB1LOm6Gg2AztMCkPfvCw8kJvB+ZVlkhF5j3Y8F6IzF7iewKCIHZPKRLP8oaMFxyb7+x iz5SVpkW08q0VjMIvFsUJD/Cb+bnqvWQzKswfLOYELOm3mE2JycWCAFfc+2LINqxTt1N6S/W oSj4GzYlAsPghFA1V8oDXsxabTR+1O2/30KxU2GOnYqVSCvxoX0gzWjtzPY66Ua+mFlaJ6Pp k7H4S8yadyCcKhgEJm4ZvQyf2yNZ4OFMO8awOcP0DQcy9ywvm4LHHIuyEQyk5sRJtYDee9m0 nLImtlBrlE3Hn1jDfpiMMLC17WwhXG0hoxWmkWpsGcSKgfS8Q71cDZCsipccTrvFtpCxquGP 7OQgjWEoXZlBNZZUQJanVVo8QbaHL6fKXnIuMaulnyU/ddarKh3w/rvZTcBtN3lUsrpD4T0I H1h//hDiXpMqbJR2ixj9Q4jx1xuj/0AUh2+nnOpkOmfX5Yusbbc22WaLUA8wPlmj4YuMam6R 5viWOFh1EP2Y25JlDFSYm/qFaG0QDMNhDFevIMaAMQYWPa2wjfZCarESTjIUnL+vxVLOdv4K krIFUOPJsTW02CscQ3ihDPPvK6tyuoEgsF//womlyvWkKqxu3tqVdLO5xc8KKuzgv4i3XyBt gehyanZ8NztWVaXl9UXbk8fjTdvfn7Gbtmqg/uKLIbLeSUyNdXjOkr1lTfXbYT30V3wVO3um VMnDR4MmcTXnw1YsIuuTvqAYOlm8gfEimi73gvfT0hvvdnfXFZfYDIzTyw5X1rBQzzm+yngJ 85PO8SVDQgiK0cppTOamVa/Mpkoqp+ubbBEkZhDc2d33tcvU8ecWzx9z9s/xE/xr9+Urvft0 3AA/wQ1wjt/Cf8K+yqz459Mfdz+BQ1wPyecORTYf3HnkpHsqasw6h2vrC/b9AX9/QHurLnAP CjGwTuAbxGsi5TzHqZaXGE2iUtI11ouvlC6kCzC8WeMCqtfj9m8d8VrVzecGGj0pa5srwKgo /kL/xwj++BkFx3yB9nbpkC0QDkM4a4LQbIvZgGFCA4keXcFpphk1U41T1W6YrG/M3NlOsLOR zZotg7WvaTcdGvOV8n62lov9q3zLKx2DhFlRd+LVSpXNt99c7D/9hd1HNviy8LVQLImoEZg1 SKyEgkdkg7Xl62QipoPPWIjTYZxOlA2ss9VgbqnXKgToGzW4XPLrzjL/ocFRjPd9nxfFaGKP +RN7tJIVNmLeFKwPaoH50xaMPw2X8H+jbcsgTMkZ6fKMMGVkBvnd7mF0tpd5LttNyRwEWUd2 xaEcZ5m+yqLO6hB20944+zHa7NzYRYFZJOwC7qNFT02uf8VK2t1T6agHuMAm0TXU+O6VmQUt 9gKPhBuZJnTPbjpawW+6ikFDtrgSY4yvwRgGZtYSMKe0FZxFyknYC1w8T7DH9G1R8fkei9VB wi3M/X3UCM96gim3jxqrfJ7mbHEmTQILnFexw7tx5BkyFeMStC2nTGyFmaKEfItL/x5Z7wTl f8PpKUe91FDLuTJDZSdvYdjdF7plNTdap6EPO+oiGotssb1w5NhKdBmEdrFlVHD4OvIodgM7 RGPAEEEalgCpcTrxW1HBaxEtGozRUEo2fFK/pSe1xgHbt/KybuDu0FbnMBAxCNwRe8lWFc4H uKI0ext1ZFMSMRNfVF7C5Rsxf16kqzdijyba2c6RNIO4yko7E+ZydOAeMVSPUX3D9EuH9cux qKKDFk4nOJ1cLRrYE87LpsI96iVmEWUJTuHWCs/MgQ4nBxyPDMdQG3Wiz3lbe/0MKcvs7gSn GfNw2VfnWIu3nr2Q6CqXMT1wCeBkwmNpqklo0Goe0voiCefnMQXhR3iz2Clqfh+rv7Wd+Ljh QudYlZ0omRR4FpRJH2mTkx0ZEN4ZypfJp0k+qY0+L5zXtQ23eHavKMyzdj+OLqdtUzZsHA0/ K4yij3c7TMOVUGxhM6fJ8mlqxKplGHj9Wc8CPF3E9nXUQfU6syJBh63H49F6zAXz/GkDq2vY rfD4KZfOHWrRrTJYSVfw1Vw3cANnyL216AZa+fvQXbIEJoMd7RPRRBE0A1E5bB5fvw1mkD0m pxS91SO1G8KpPM+Y357BMTaaiwu7qc2nhKTUdhMvx/iVdY22UHuucrg9Z/vN7YIiX7aiGy55 qFQSJTxDKDFCLd3ukXWVPc++AzU48/dERTkNHabF/Km2Zt6NsRmkpF5epdshnI92fTw6/e/Z epxvv7n48fGTn3852kbqc9Jai4fW22wio5G+YlO6uaw2Ef7NZS8noRszEVMpXz1IzDsDzQo/ UdYiGXhl0kZrtc0X1Iy62t7o8+/dpeO28KXSQPPJILqVZAFUgy2TkVO1texyyeAauSeDdYxe 9hJbC5eqY8SnmIztnU+/RxCcn+T6XXJSeSGMBH2znTGreffJzz/+8xFDplP0LuFlb9BecLLS PuadmT0O2p6mTwg/hjYYDqYcFY0WS0Zriu+fTkXXC8hb3mNDOE2PEp00wTKcyGlgRYTzIunS vkmu+qxy6k9pTz19/Hi2//3B92zx4TyP0zGU3/fKyKzFjgu0nDZWmrEaKBtUbJqd2sb0ksLg BMNTJ0b+y0y1hFMGvqTqvlkxY14/fVvyUYjvv/8Y6I3p6W9vPuydHc7ezw8RDa1YYMbbhfCh EaxknsOK5DeRtFWEIA6DuHTgJaWIFqOzIoczt8zayA7zrF+BDQgj8vrE61mAv2wTt7Y5FqWs bgiUKbUgvumdj9dRK8aehyNcf4iWlSv3OL51VTz8IWrfeWypzMX40jzX2vMig3Q0+VchAWaU 9/b43nWenLOWQQS+CAN8WuNLXGElneM0Tc6XmCW1tIHNPy5IM5e6HZUTwcBrTHa5xYh87iXx J/PgZ2gd+JovhdrM3mbt1oYT81Imac4FXonOMgy8rJWN2RoOv4KbK2N3z1QhQ6YO58WIR18z b7l3IpfnAhOrd4ofFeqvScvr3gLnp2mZ0TWDH2SlQzADBx9/rdWB4xjMsG6NMi0zxPAtw9zW 9N7PY2c29aTeTlKbx86NZXHCjBUKaXqudxlE4NIxGnB+D6ft7lw0wmWqRUxDOY9tZIFgj7Mf 5tFHhnCBEUa3AC77AS+AIWEgWzxgL+dMqJyJD9j+O1OdmSKDMGD2hrO0r1iueJCYGFeG8SkJ gFB1Bl22ZBBLDLFEAC2mwLat1GIKUsGgaUjhSI85zpvCKOmbb8Yo1u5rxpURNN6VoywKBTgC Ltdzllx939zKE3sY2u86j/f7ZBCePXcIveKLbnaqvDKTcHljabzqPH1OFPA7tbPYFZHVTg04 XnkWe5Xn0QX8Ku6K0i/LvwpLrKbiUkxCfRpw9mASRdEYbqzoanlfddEFxolObc/39RhzZLHG iN88v+dPnlN7CmIqmeyQThmJMqGW2Fz7wFK6lrj21wcLp2SF3yz9Pr5Zyo5ur3A0/XehYTRr ha+4fk8e1MAgPIbwjKpyxUuGX1dXypuYCzwxR0Lffjz9RdKLcowuahCYHlxYBtBjgB4myQ89 3VF/pHO3zZu1S9yhP0Vvg0Q64hKvxD+lESyJ5hJr7T/F7TdtWwjTcTciu8C/vLiApRpO7Gz0 FaLy4+VKaU2QZtOW+WSW3ICM1YY4v+yaAkU3310D0HH2306uM3HugtgXWj0Qc+fdEHnUevf+ vsR80+NP1txw3omg8SPA8Sd+6Aqr/b1RbI/5LdNPOntu7w3hcLLA+JNOAQDFAdSaCjB3IsRa PRCr4d0QDWYBjo2q7vv9A2E8NpLVuZLVLP30is9+tldYp1K3hJ7NB61HreLvj+/Uek35j90f n9xJKHh/pTKSaGXwbt3/8/KhKMruhFCYqnz8SXPv79s+PAhX2J0APe/A0Dtlw70RBof5FQeX tjroxOB8JsRsZ8xfOGiiK5vZeJ1sx5rky6tlfJu14y4BPtWhQPxESzGaX07Ndk6u/nl/NI/n 7EVSa06G2c6xdZ0194Y6rIcql/ukkp0FKzH9rsmFapRMTgzC6v8TLFvroW/urUgPA06ZHn9i +3F9vpLjw6z9/V/k5aMNbtznP/jb7aZ3yvZK8uJzTQw+jgt3z9suiKWLWl3V0jmJvk1bSRF0 XJ89/aS+yhI8bhtZjdj3h9P44cT4k/E57P0X11jZ/UGKwd8J4GSbU6b93t+PCzwpcSHGHXh/ CFxoLv2ki21zb4jXApv740+inu2M/0yb7sn/9natTW0ry/avqOpW3Z1dB+fiEHY2lVunCmxj wM9YBgLfxtZgTyxrvEcSYP/6Oy0ZwkOCXiPuqTp1NiTRrHn2dPd0r/6r+T3c8eg3mYZ/AsA4 r3uUoW7UjtcR0S+Vof4SCKbGMdNI6ww3pXD/473vGgGMXQbpq+UqzHVU9JK13ycukGNjVWH6 1erAMKacoEeBPpF3bACcb5o+mVndgQ2xjPBssbm4m3uFjPOlMGaBLs8na1uL2LvRxnsYlPcv ewCsUW9/5C9SCg8wK15iP4PMlVOc5MB+ksZ0xIxYrQRf7zpNYEcvDYk+IxWglZiUqlHueIP8 PzKZfmaDnwlYm6VPENP5bFVIkPaWaXlGWTQWwnu6a+z5/lelvdPB/VodsRZzr6v4EBHOHZ4P gw0xx6mw7Sc6nif8C7UzX+Igy9fRdaXtZ8yP4DxFkQjY09QtXom3dl2XEPjta5iMUmh+68kN 3Hqi7A14bMQiSQ18+9nPZ26IbSFDBzv64XkfBWS3L1dTmIh2NZ0L79Mo15CiGX8wCn5Ip09S fvuwXLGfSGG8QwBi4gZxxIZYT1EnI33Cv7W76wAHCAAAooZ0YZOUCMRaONFtOTgrehLOGKZP EAu5F8JMID0R2gGFfOdvT8NKYcYGHSIrv4ZvxJ5dlaU9H5+OrDlrtRm2NHkg3UECz0sZfUpR BjPYIz+YAS75QThdgIdxEHqNuVpQBLX9SS5l8gclne142/RD9gwODMyWSZ/oiA8An9KBUWu2 ejHAk5bok4iPMJRwzVoyO+gz/ukfznH2EvtJXFvxxzGP7j+MM6IUJDQBTBgRhsLYCbO7SgIC 84cgKoUfYnL/cVwKZVgjDcv/EQlOU5SsUwqSRjDBQRrxJ8wXsFvFhxyYvigsPvyWIKNPhLW4 DHsb+3j5RvvJbeYcp2/ZotHHK6vRJyLkD6U44PPN+SIyV8Sp4K/hAnv0SaK8vpgZ/tKv4cIy xUlGbwBIJwDvUyu22yuayVDDtpdt4pcj6qXMa3g7QEauAxVukGMxm8ApHLOJiO4EHyKUDgli XQkAwJSZ8s7LQFIAZRniyS4qZLcv4VHQJ7OUDwBbAPTJnWB7rMY3OIK6sWY7Vc0+kmZSkFRR ijULZ/jGFaFmO/DHc5jBjj7hu8fGeMHjcUHNlNLm1QTOIMzJCrgIlE3xQQkYZRAXQn1AukJp 6ypG4x7sJ2pC1AArKafsuKWfOEPd1pCIAQ38J55U3EgjqW60WVr7kfKLde1wsRCIu+dKwSt0 xV6g6/t7eEQ6kNljSBrd2a2WyDdSC0ph1+u1O+zvvBwv/3s27GazcYed2h/fRTRytk0kyyOl Dz/OgNo2/RqjicZiR4E2r62C0vZbeFBoYmeKYsq91pLSPV7vjFKwY3QwNzNi1IsLxGopRhue sETZDZ6FHB0JM0kD/uSdwlizVIUhH6AL51hOREbuzmy/5xbpz26/D6uWlBxqRU4Qe7QwYQjs rgG+GhpYix/4xhJmaq9rPsQIXo6ZtLMU8RF8FOGBTc8XS82HGbuUEgP21blL+/TUz0a4hJci nfBb/wm2/t//dd/Y/07nwjuNs+PBhrpGB7KxtoRQv/gi9+gQziCJrRDJJO6JNBs507fAHj46 ghN77IACzZ6yoyYMEM1CYf9kzoZowclD4Uy9Jigpbf8YziUxC7sG3rGINRukDYOEWZAUG+AE Xoi5EYq/cU/xWbIaqmK3f4aniAG978GtmyWg3Rz14aQqsoe8pjBpHBc9r5YiDWABEqpbYB+N 8PSwzWvnU2nzPr5NxVLw5RF6mx7NU0BjPjrHT8GSP/cX8NqmtzLZXnNslEsYJYnvBHDpXOEC m84Bu/1rvH21kdzmG+gVneX8sWen0YAt76mOqXCypFzoP1GlptGE8ayuv+ON59JryqWeZgk+ 3kiu0gmFlukbz9odbHT0cm1YJd1qn97hTa5LP+CyAdsuw2W3jt6y/p1KNrmVxsZAb9oGRch9 /Z5IL/jj9FYrw1+dDjxZegFvwC6cC6pC/hB68Gkl76Nmi/xGH+8+X1Y2BvAKhHo54d/njREM ECfCGwGmeMPHuT8nW5uml3E6yJnhH8Fz2PPMNzYbF/BuWknvQpqAv2F/wvvJqDixOhB4zzeu HPKL+bdwA72FGxs5ncPyvNmE0xSpKmXR1cWGbDlBrtnto6ZO85ea6DRh21LNDpylTLGRC3b7 qMxt6qWKAInSHDgC4PpCE/b5hDMJ2OUtVN1rTVMRaMNuH92srTjRgFu61XbJ12a3jupTDxEv Oa0zG2YElzFWiZH89uEbcAW4Xlpjtxx2dvePUY3zWEXITXR8Brf/iy3sjlFhdyzCxVPvsPep J0JyqsZ/sjF7cD3xqdGRjJXY8Y5lQKQJMvD8hF4ErUXFxh3AYzVaogr7MXpajg1VpmI3/xPO ckiM3pbG9jCsNmrLt8WEbxq0j9wehDvWjg802+XXbuKkA4hHot1yY4Jgt38M7ycZWVWxnSrA 69Rul5HLfTko4TWwF0ks2WpbG72r2nOk+6gMbquJEWEi2JpCu+vAXQHJ+XYPPm2IKdvuw8wV lBPHbn4INy8CGep0xRdH6Lt4659UJNqqm6EHDmbksNiAXPWd6s1tBUdm+Sdz6eV/SjX17pQ9 8OA91R7jC5bIpeDHMbTPcQS+WL902s61IxXHr6oKlKNcwShrQGydoNrXiY5mXqeA3qIUoQfz gFCmT76Xch/TtEkcJHA4wEkfH1tAqSZsANg3Z7RI+ALzZAzTtii+l+EEPRw57wf7vj1t4pwf uY7NRmjBlfckch+eojfuaWyEZL+lnvZAjcfuf0nvNz3+g+dpH18EYAHgx2yK6Y7nD/VKB1NJ 1aqksX+sgZ31A1538Q+78RHeeLSTyabl83c2NiJ6GZ9OsW2MihFiw2EvxlkL3MVn0gBa+1kP ZtShGrHsLXyGbuEzbQL++Tsbwt1f8VvvoAKwIwuSmktbR12HnbWZrTdIBHPnBH/9m2hAQnVQ s6yjjJoI/i3agd8v9VIbfoBepw+n46oo8ToqSeKcWlLeKj4aul072kix8/S1Zij1KpR/xC6S sDNyg3eBQrX3TnonFNsx3oEf78Sanr1AFbdzDRM/bcRijhzR7iHOzPR7E1R4xusewYxDExHx vX/dhtPJ6qZTvvjpnsIsQHI6T2QUJ5L/wNDtwGVCFdWDXvDHMYLHMUFe2bo+vNaxTubsoIPu GO5/Mk+R9JLuOVw3+F7auyw1bEu6e4FTfAGRo90rfI2JKilLjyKta66KSFnK4HqHMMuQ0dMp e8l7DZzFSADNN+Hmw0Dful1WvTbM+hSImYinfO9y7wSGMPFchCF6ZfU6MNBUBvTkncc0Hmuz lMa7SmfaAt86TWcXJ9FiK4S9nhuzFbv9viM7FxtggC+Q4J8bVMPsa5OXj+9ljBUC3m8/8I2d qEj9k7K96b0RDJEaeg0FFsXHVz2JpSkoUVYKMcZPRcIfwLnTHCl+QFvvAu9/oG75SZe9Swfu vTu+4MDf1e8VcGFduTAHAt7Y3jW8RTf0fggctD6qM/TFUgEvlP2GAz1MQ4T5/cRGQb02fTWT 7Puhf4wL2BsdLsDo1H7bZRDAJJ3C7VttR8xSPkLXPWGbjTHAF+NOsJ2jffgylSvBfp/oj+DT llWnYLY+hvueZpkl1zriC4xzeBcB0ujaQVpcS4EcswGqTQ6WfNfOECb1sPoXPx1uiMq5oeRv n6FjUNJQh2vokXHYhidplQqP1hoL+RiewMybKlSrFZXeY2N04MEsIEqSYRdn9gSOw7Dn5LMb KqsJyzyYgPSNkO8lHKLm1lAlU6EMHwCVssNUmkRThg9b9xv68LKHMk6yWu6/n2d3vMF0mq6U 5C/XGN4NJkln/CtqeIkPjB97M7yCW880EPb9/QMVwD8EEDD4o/f584/r/3/ephEq56kkQOvg exop/jkcDWBu3SViYI/OYVrdmCjXHsLBkaGgm3Z0JyJ+OLB/CMvINFCZG5c/Xf4RHEAY6qWG H7h8+JFGrqdziXAp+agn10+BAAC/BWcc2w3Fb76N0w/PxErzc4z9E6cr90SGkh+G6KPWnh/q W4Sdy0dTWPxbEU4oEJGUhjNB7sc1sCwdh/FYVYs/ni687uQM9LoSsJ58XNvK3bQRWzPx4fAG yjbmKwj+AJZTS4Q7yx/BwsNOj1jy12AMr4H2xnqZa7tDCzZV/AB3/xzPiLFCXd94vr5VMrH/ mSo7f3Hy+C7Dl8Oo/7YVer4Ib5FsS//KhTZ7+8aJBjD417DoJyoewBwao7fjODWLPCyoIRTR koDX8biJlx3nj8bRpM+yEOiF6MFSUfzLf4zen2PNZxsZnziwNkPrfwYzW/9SmEE/7sATtJCA jTXuwtTTS21qXcojZmP0HI4JkX9CE9WHQSwA/6YZD+CFsJoeu3XUk0x1BLxsLdgQI4dV4AcK j9GLcmzvRhWIXMMb64kADvYFPJTbrPYAs/lLvAzCHQWhDw2xS06zJAGIxmZ8DSNGG5HFZGxz Yh3CMM5RQ/V8QYyH7GN/3sY55wE7+7znlj28zRrvWS3ZeIM0CdfWJEMv4nO/CjgbBVWXzk2K +L/O0W13vplI7P66OISTwMK150vpfbqgsFWr/DVUss4njk0wcOEWW3pBh9f+9yG/Mk8ERxz8 F6i74cLaU5tU8nMqL9pwIQQzU4+Onx1vmwPExjutiHf+2f/MBuvDYNbo6fOTRi/O4SIVUSoS 9tVxierQlyK05lq2447TJOVfGZdwCjHCqv3z8PPnn/8B3/UVatBcSasYPk14YCO1XJDYrePB W2ud8FXoK3TfPsRn8hXc60OnnPScaJINgl7a1xDFwfUIbh6ge7xG9cJrtZyIyR0f4D9w4nZ3 66iI0iYM+M1/gQtvIBvItuW2TfPiAnyYAzTwg3Jp+Tt1t153pO4C56u+58ogC85Y/auDCesy oH3XCGYU6BvMUhUEoYRh/nbZ0C7jOXAryMFWfne/1J2XBtxsXw7g/D6jJhPJN1x293Zd9zPg Vdrd++q8+hCMk9SsuQ3pwHVIrdRo/mPJ7v6ea2mWbWYuHA64u/8VDhIPBRTvtrv/zZkcj43x Vx0PE8PC9upfYT0Aat35VoNQ9l3vaARlHxY00DGp79cdBRmK89VV+qNArsuC4XyFL8yuNUgf 77JHL9L7V8+2GPDvER7ASvrYiEDRT0R1llM40+zqmRGr+UuH4MrIG3X/byLd3v74v//z0Iei 3hz85UYi/aQH5BLPG6rQk0gGxKUABsUnKrbi0QuUCOX0ZTrW838aqI0o+Yfb7sUhq6dGbwRa lXokC2qIvv4Hr1wez//JpqCc1tt9twsUBTeCjiJ1iTosTFIL9a8JtfR8APVanf5XvP23Xzzf 5c+bL4SbyrA2E2mYuSVf4tk5+7JfQn+4/QQGlFFtonWUvETbq+1+qZEhU1jGxX5AJUTc8NpH NU2Ru68Av9V2i4l6WtGMhrfjDe5vtAm87e9eU02zg27WXrySoXuX4qlOqUr98y7tvjHj/vYL GE3VxFI9Q7LC4OANpMPla9YUFs4kihCcozRKIyegQN7Y/Ze8BPubqJfquyU88dknxP2Q1bl1 wpWRns7V65P5JdtKeyVb6eEbB8C5WBTMaL22Vy8hwVu8JrZgAS1oK+uS5SvhU3n4xAEupCLM z6HoLNbqB+8QRrjJHFVbqqxUDh+ypwpq67CgInErfkFY/e0XDmCrO+jIDbPXciekRGgEaSy0 I8wag1m/jojkAcUpBBTr1AEn0va2e3WG92u7f9e+7JWmQVrl1KpwR3qxdBqcBY3WkRtofx1p Ey8cUONZVDtq1W4MordkBS9FVHuIZ1OzqIqI3vYhCp36EMolXfIf0YnGSS2QSCf8OxXHD+ZD 1R5s5rXp8tUttU+3VH2/5E0sCih6OYudkbE7aO1ERHEVZO+Tr5arUN0oGfxZqRtJtW48Mesc +zETBcK5brXcv0sIyshs89pOAprgUr1OEcDHMVtUP8l+CaptgHmugPC74KqxWKylgmbXXug7 3nG6met0xzvRi4Wix+zDpV7v0PjzODLngdvO2Iu/wGQjMtAy32EUUeTai748dmTnd3Rv1vfH 3+wofqntl6F+8hfHad7QibYWpNs47lJoB/lzK6TmQtGBsZN4mbqh3tvhzBDcn/QBIZ6kUYVV W6cSQW1YmaI5aPb/U3uayCmRmfSbGkXRFxig+7W93XfKcytP5UH4aurlf//al/WAVoTcWJuw ArL9XIWhI3ZXJFEF7NynBwNPZCHwPhlOu2+WcSUFqAJuXDjZ+5lj49sbJdKjahNtcUvGy8F1 HGwga7mr9JXA+1YGmis3O17yxF9a7ih9F5wcmjj4+37Rd4APx84Dz97AaNq3DsAPmoqsR26z 8bpHlefHar6u85PrwB87OVl33CbnRXcqz0yz5TwzW7vgY6cm64/b1LzsT7W5kXEte/Dha+vP XnusvbSyN0ZRXG0ppEprjWJDpVRmnkbpIlFJmmTSmgpnZ+lxE23UTNFC+OswdLumbW9QCf6s N44y3JpJ6IX1wKhY8cqyyD39QuVDkH//AkNnLoIR5B8wlJuo3rPL38Gkcsl8zIdaydUwqRws H5PjfHgPsIMANrNTWwmQylcCTpZVdcRjaO9w/FrvAFKpvgKrkoI93ygzUgkRGiKV31pUwjtt ISM8NVXHR1VB+OOjkiBVDyLVwuAjZoUwyKSuAkmcmnzIjFCz4iCJt5C/jI+khRVBu5DESZOK p7EPifHffvUqmENov+ZEUmnV/eO3MPc1xYdUm9pzH9k/v5W/CpCUeAEM8knWRQXcsLYNpnmO /LVGtYPqrEiaHe/NgJl34LcRMi/9MvXdsnCIPPqF+NvzKBj6qSjY5U1cA7uifGkmlVVNi4u6 oZ7gOmrWyazQ4/eWfpvxE1Tx9VlMVJt/xHSf3hT3MGaZrJVR0UV9RHVc0rWqhcWQZDAXJ4Kp IMiiiNxRN/PCB7W3Bho/Pp+VveW8j1dr9Av20ddafa8kF6rh9UReWf3xAY2G+7srriOvnXSK e1J/u0bnR3ejN0C6kdUF+OguEOEZvwuPbGcf3Q2iaOB3I3/O+tg+JMhxeOoqcz0PyQedh6d9 cR37RxyID+lHxRPxIX34gCPxIf2oeiawTmTR63Fi1v/+P5lLauS8qgEA --zYM0uCDKw75PZbzx Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --zYM0uCDKw75PZbzx-- From ltru-bounces@ietf.org Sun Sep 17 11:45:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOypU-0000LP-Iy; Sun, 17 Sep 2006 11:45:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOypT-0000KC-Kk for ltru@lists.ietf.org; Sun, 17 Sep 2006 11:45:11 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOypS-0003RR-B9 for ltru@lists.ietf.org; Sun, 17 Sep 2006 11:45:11 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GOypL-0005tc-C8 for ltru@lists.ietf.org; Sun, 17 Sep 2006 17:45:03 +0200 Received: from pd9fba9c1.dip0.t-ipconnect.de ([217.251.169.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Sep 2006 17:45:03 +0200 Received: from nobody by pd9fba9c1.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Sep 2006 17:45:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 17 Sep 2006 17:43:26 +0200 Organization: Lines: 30 Message-ID: <450D6D1E.6AAB@xyzzy.claranet.de> References: <450B2F27.FD7@xyzzy.claranet.de> <20060917143445.GA10307@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba9c1.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [Ltru] Re: DOCTYPE ltru X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > May be we should use the same vocabulary as the RFC 4646. For > instance, you use "date" when the RFC uses (except for the > element) "added". Yes, I wanted the same attribute name for all dates. With a DTD some ABNF details are lost, I've used the name for a hint about the real type (NMTOKEN isn't very precise for dates ;-) > Or you use "tag" when the RFC uses subtag or tag, Same idea. In the version supporting ID-XREF-checks I could keep "subtag" as is, and use "tag" only as attribute for the grandfathered, redundant, prefix, and deprecated elements. > I do not see Preferred-value in your schema? It's the optional (#IMPLIED) "tag" in a element. If I'd split "tag" vs. "subtag" a "tag" is syntactically the same as "xml:lang", but of course I can't abuse that as name. Your RELAXed spec. is Greek to me. That's no problem, but it also won't work as is with a DTD validator. With my version I'm sure that only descriptions and comments are "text", the rest is either a "date" or a "tag" (modulo "subtag"). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 12:22:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzPO-0005bu-FX; Sun, 17 Sep 2006 12:22:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzPN-0005bk-Ka for ltru@lists.ietf.org; Sun, 17 Sep 2006 12:22:17 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOzPM-0003Yg-CD for ltru@lists.ietf.org; Sun, 17 Sep 2006 12:22:17 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 368D4240814; Sun, 17 Sep 2006 18:22:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 7984911970; Sun, 17 Sep 2006 18:17:53 +0200 (CEST) Date: Sun, 17 Sep 2006 18:17:53 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20060917161753.GA25501@sources.org> References: <006001c6d804$bb837060$6401a8c0@DGBP7M81> <3F8B0FE9D86E40178302D77C1CD8B8D3.MAI@home> <450A63A1.3A81@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450A63A1.3A81@xyzzy.claranet.de> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@lists.ietf.org Subject: [Ltru] Re: Registry Format X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, Sep 15, 2006 at 10:26:09AM +0200, Frank Ellermann wrote a message of 160 lines which said: > Just for fun I've created a gawk-script to convert the registry to > XML The output is not well-formed XML. Here is a patch: --- ltru2xml.awk.orig 2006-09-17 18:08:18.656912781 +0200 +++ ltru2xml.awk 2006-09-17 18:08:10.536819185 +0200 @@ -89,7 +89,7 @@ A = F[ "file-date" ] if ( A == "" ) exit FATAL( "missing File-Date" ) - print L A "' />" + print L A "' >" } for ( NAME in F ) delete F[ NAME ] @@ -116,4 +116,4 @@ } if ( --NN ) print "" print NN " records processed" > "/dev/tty" - } \ No newline at end of file + } _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 12:22:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzPO-0005by-IN; Sun, 17 Sep 2006 12:22:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzPN-0005bl-Kp for ltru@lists.ietf.org; Sun, 17 Sep 2006 12:22:17 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOzPM-0003Yk-CE for ltru@lists.ietf.org; Sun, 17 Sep 2006 12:22:17 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 0CC0E240815; Sun, 17 Sep 2006 18:22:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 416EE11970; Sun, 17 Sep 2006 18:20:41 +0200 (CEST) Date: Sun, 17 Sep 2006 18:20:41 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20060917162041.GB25501@sources.org> References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450B2B75.2F36@xyzzy.claranet.de> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sat, Sep 16, 2006 at 12:38:45AM +0200, Frank Ellermann wrote a message of 36 lines which said: > > if we move to XML with IANA concurrence, we'll get UTF-8 anyway. > > Several issues here: Where does the "IANA will convert everything to > XML" rumour come from? It was announced by David Conrad, director of IANA, at the APRICOT conference in Perth in january 2006 and confirmed more recently by a private email from Kim Davies, IANA. You can email them if you want to check: David Conrad Kim Davies > IANA can't simply reformat all their registries when they feel like > it. I disagree: most registries have no format specification at all, the RFC is silent about it. I believe that the LTR is an exception, not the rule, since its authoritative RFC mandates a registry format. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 12:22:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzPO-0005bu-FX; Sun, 17 Sep 2006 12:22:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzPN-0005bk-Ka for ltru@lists.ietf.org; Sun, 17 Sep 2006 12:22:17 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOzPM-0003Yg-CD for ltru@lists.ietf.org; Sun, 17 Sep 2006 12:22:17 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 368D4240814; Sun, 17 Sep 2006 18:22:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 7984911970; Sun, 17 Sep 2006 18:17:53 +0200 (CEST) Date: Sun, 17 Sep 2006 18:17:53 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20060917161753.GA25501@sources.org> References: <006001c6d804$bb837060$6401a8c0@DGBP7M81> <3F8B0FE9D86E40178302D77C1CD8B8D3.MAI@home> <450A63A1.3A81@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450A63A1.3A81@xyzzy.claranet.de> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@lists.ietf.org Subject: [Ltru] Re: Registry Format X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, Sep 15, 2006 at 10:26:09AM +0200, Frank Ellermann wrote a message of 160 lines which said: > Just for fun I've created a gawk-script to convert the registry to > XML The output is not well-formed XML. Here is a patch: --- ltru2xml.awk.orig 2006-09-17 18:08:18.656912781 +0200 +++ ltru2xml.awk 2006-09-17 18:08:10.536819185 +0200 @@ -89,7 +89,7 @@ A = F[ "file-date" ] if ( A == "" ) exit FATAL( "missing File-Date" ) - print L A "' />" + print L A "' >" } for ( NAME in F ) delete F[ NAME ] @@ -116,4 +116,4 @@ } if ( --NN ) print "" print NN " records processed" > "/dev/tty" - } \ No newline at end of file + } _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 12:22:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzPO-0005by-IN; Sun, 17 Sep 2006 12:22:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzPN-0005bl-Kp for ltru@lists.ietf.org; Sun, 17 Sep 2006 12:22:17 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOzPM-0003Yk-CE for ltru@lists.ietf.org; Sun, 17 Sep 2006 12:22:17 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 0CC0E240815; Sun, 17 Sep 2006 18:22:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 416EE11970; Sun, 17 Sep 2006 18:20:41 +0200 (CEST) Date: Sun, 17 Sep 2006 18:20:41 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20060917162041.GB25501@sources.org> References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450B2B75.2F36@xyzzy.claranet.de> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sat, Sep 16, 2006 at 12:38:45AM +0200, Frank Ellermann wrote a message of 36 lines which said: > > if we move to XML with IANA concurrence, we'll get UTF-8 anyway. > > Several issues here: Where does the "IANA will convert everything to > XML" rumour come from? It was announced by David Conrad, director of IANA, at the APRICOT conference in Perth in january 2006 and confirmed more recently by a private email from Kim Davies, IANA. You can email them if you want to check: David Conrad Kim Davies > IANA can't simply reformat all their registries when they feel like > it. I disagree: most registries have no format specification at all, the RFC is silent about it. I believe that the LTR is an exception, not the rule, since its authoritative RFC mandates a registry format. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 12:27:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzUA-00079K-EH; Sun, 17 Sep 2006 12:27:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzU9-00075s-83 for ltru@lists.ietf.org; Sun, 17 Sep 2006 12:27:13 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOzU6-0005Tx-VQ for ltru@lists.ietf.org; Sun, 17 Sep 2006 12:27:13 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 94E2D240815; Sun, 17 Sep 2006 18:27:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 876A411970; Sun, 17 Sep 2006 18:24:51 +0200 (CEST) Date: Sun, 17 Sep 2006 18:24:51 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20060917162451.GA26526@sources.org> References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> <6.0.0.20.2.20060916114849.081056e0@localhost> <450BD347.9EA@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450BD347.9EA@xyzzy.claranet.de> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sat, Sep 16, 2006 at 12:34:47PM +0200, Frank Ellermann wrote a message of 62 lines which said: > I've no clue what FTP clients would do with something like that. > John's "net-UTF-8" draft isn't ready, and I had some troubles to > understand his last published version. John Klensin's draft-klensin-net-utf8-02.txt addresses a very important point: how to represent the end-of-line? Try yourself now: the registry transferred from the IANA site with FTP or with HTTP does not have the same end-of-line (and that's what crashed your awk file, in the bug report I sent you privately). I did not read the record-jar draft yet. I hope it addresses the issue. Otherwise, this is one more reason to move to XML :-) > We've no clear idea which tools will exist for the 4646 format in > six months, how they do their updates (http or ftp), and what local > conversions they use. Doug already proposed that an UTF-8 version > might have to keep the & convention, that could be confusing. > And we'd have to decide if a signature is required, another change > of the record-jar ABNF. This is the sort of things that happen when you reinvent the wheel, and create a new format for a registry, instead of trusting existing formats... _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 12:32:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzZQ-0000sU-Nn; Sun, 17 Sep 2006 12:32:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzZP-0000rK-7S for ltru@ietf.org; Sun, 17 Sep 2006 12:32:39 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOzZN-000703-WA for ltru@ietf.org; Sun, 17 Sep 2006 12:32:39 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060917163237.ZJDZ10468.mta9.adelphia.net@DGBP7M81>; Sun, 17 Sep 2006 12:32:37 -0400 Message-ID: <011a01c6da76$e3706d70$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <00ae01c6d9e8$a3deb740$6401a8c0@DGBP7M81> <6.0.0.20.2.20060917154346.08a01070@localhost> Subject: Re: [Ltru] Re: UTF-8 Date: Sun, 17 Sep 2006 09:32:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: >> At the very least, there would have to be an AUTH48-like period where >> we could review the end product and make corrections before it was >> publicly posted on IANA's site. > > We got that last time round, so I don't see a problem here. I got an AUTH48 for RFC 4645, but that was after the Registry contents were stripped out. I'm talking about the actual contents of the Registry submitted to IANA. So far there have been three errors in versions posted by IANA after adding incremental updates. If IANA needs to do any sort of processing at all, there should be a way for the Reviewer (or his proxy :) to review the finished product before it is posted publicly. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 12:42:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzig-0004Ao-Os; Sun, 17 Sep 2006 12:42:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzif-0004Ah-E0 for ltru@ietf.org; Sun, 17 Sep 2006 12:42:13 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOzie-0001dW-5z for ltru@ietf.org; Sun, 17 Sep 2006 12:42:13 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 23818240814; Sun, 17 Sep 2006 18:42:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id EF6A01185A; Sun, 17 Sep 2006 18:42:03 +0200 (CEST) Date: Sun, 17 Sep 2006 18:42:03 +0200 From: Stephane Bortzmeyer To: John Cowan Message-ID: <20060917164203.GA28821@sources.org> References: <20060917061912.GB26073@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060917061912.GB26073@ccil.org> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org Subject: [Ltru] Re: RFC 4646 production "grandfathered" considered harmful X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sun, Sep 17, 2006 at 02:19:12AM -0400, John Cowan wrote a message of 58 lines which said: > 2) Add an explicit "irregular" production in place of the "grandfathered" > production which explicitly enumerates the 17 irregular grandfathered > tags, thus: +1 (When I wrote a parser, I suppressed that production from my grammar, replacing it with a list of grandfathered tags, extracted from the registry. I prefer when the parser's gramamr is as close as possible from the RFC's gramamr.) > It is safe to enumerate this list explicitly, as it can neither grow > nor shrink. Yes, that's the big reason for me. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 12:52:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzsP-0007kY-Er; Sun, 17 Sep 2006 12:52:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzsO-0007iH-4J for ltru@lists.ietf.org; Sun, 17 Sep 2006 12:52:16 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOzsM-0006BW-S6 for ltru@lists.ietf.org; Sun, 17 Sep 2006 12:52:16 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 0F2F3240814; Sun, 17 Sep 2006 18:52:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id C3C6B1185A; Sun, 17 Sep 2006 18:50:50 +0200 (CEST) Date: Sun, 17 Sep 2006 18:50:50 +0200 From: Stephane Bortzmeyer To: Mark Davis Message-ID: <20060917165050.GA29413@sources.org> References: <20060802072709.GA17404@nic.fr> <44D21ACD.4040707@yahoo-inc.com> <20060804165720.GA24037@sources.org> <44D4AC42.79E0@xyzzy.claranet.de> <20060830093000.GA31895@nic.fr> <44F6313D.2070000@yahoo-inc.com> <6.0.0.20.2.20060831201004.101ab8d0@localhost> <44F6EF0E.20602@yahoo-inc.com> <6.0.0.20.2.20060901024806.109a6d90@localhost> <30b660a20609161628t22ab3c4flc81ea92f40800a09@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20609161628t22ab3c4flc81ea92f40800a09@mail.gmail.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sat, Sep 16, 2006 at 04:28:01PM -0700, Mark Davis wrote a message of 98 lines which said: > BTW, I had updated my regex to the final spec for 4646. Here is a > single Perl or Java regex that does most of the parse: Isn't it too lax? When testing it in a Perl script, I find it accepts all my well-formed tags (OK) but also accepts wrongly: fr-Latn-F is well-formed en-a-bbb-a-ccc is well-formed tlh-a-b-foo is well-formed abcdefghi-012345678 is well-formed ab-abc-abc-abc-abc is well-formed ab-abcd-abc is well-formed ab-ab-abc is well-formed ab-123-abc is well-formed ab-abcde-abc is well-formed ab-1abc-abc is well-formed ab-ab-abcd is well-formed ab-123-abcd is well-formed ab-abcde-abcd is well-formed ab-1abc-abcd is well-formed ab-a-b is well-formed ab-a-x is well-formed ab--ab is well-formed ab-abc- is well-formed ab-c-abc-r-toto-c-abc is well-formed abcd-efg is well-formed aabbccddE is well-formed _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 12:52:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzt5-0007pi-NZ; Sun, 17 Sep 2006 12:52:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzt4-0007pd-QC for ltru@ietf.org; Sun, 17 Sep 2006 12:52:58 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOzt3-0006bP-IB for ltru@ietf.org; Sun, 17 Sep 2006 12:52:58 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060917165252.WMYR28624.mta11.adelphia.net@DGBP7M81> for ; Sun, 17 Sep 2006 12:52:52 -0400 Message-ID: <011e01c6da79$b7f17330$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 17 Sep 2006 09:52:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: >> John's "net-UTF-8" draft isn't ready, and I had some troubles to >> understand his last published version. > > That isn't very relevant, except that it suggests normalization to > NFC, which I assume we would do anyway, and which is already an issue > in the case of NCRs. Both the current Registry and the prototype 4646bis version are in NFC. Frankly, it hadn't occurred to me to do it any other way. This raises an interesting subpoint: I suppose either 4646bis or 4645bis should state explicitly that the Registry is in NFC. >> Another issue are fonts, for RFC 4646 there were proposals to >> restrict the registry to Latn. > > Bad idea. Any average browser installation has way wider coverage. I'm not sure whether "ASCII," "Latin-1," or "the Latin script" was intended here. More below. Frank Ellermann replied: > Or way less, almost certainly not "all Latn", the next least common > denominator after Latin-1 could be MES-1. The Registry presented in 4645bis will tentatively contain: * 497 instances of characters not in ASCII * 4 instances of characters not in Latin-1 * 1 instance of a character not in MES-1 (U+02BB, the "smart" apostrophe/modifier letter added to Ge'ez). It is in MES-2. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 12:59:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzzY-0001s3-PJ; Sun, 17 Sep 2006 12:59:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzzX-0001rs-LL for ltru@ietf.org; Sun, 17 Sep 2006 12:59:39 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOzzW-0000ZR-EE for ltru@ietf.org; Sun, 17 Sep 2006 12:59:39 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060917165937.SEEG27224.mta10.adelphia.net@DGBP7M81> for ; Sun, 17 Sep 2006 12:59:37 -0400 Message-ID: <012001c6da7a$a95c46a0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 17 Sep 2006 09:59:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ltru] Re: RFC 4646 production "grandfathered" considered harmful X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> Add an explicit "irregular" production > > Interesting idea. Maybe add "zh-hakka" as "almost irregular", or > let's _define_ hakka as deprecated zh variant. "Irregular" means "not conforming to the ABNF of 4646." I don't see the problem syntactically with "zh-hakka". It probably would have been made into a language-variant pair already, if not for the fact that ISO 639-3 will allow "zh-hak". > For zh-cmn I hope 4646bis will solve a "missing cmn" issue as side > effect. There's no problem with "zh-cmn". One grandfathered tag is the Preferred-Value for another. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 13:12:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP0Bd-0006GM-N5; Sun, 17 Sep 2006 13:12:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP0Bc-0006GG-6M for ltru@ietf.org; Sun, 17 Sep 2006 13:12:08 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP0Ba-0005ne-Qe for ltru@ietf.org; Sun, 17 Sep 2006 13:12:08 -0400 Received: from [10.72.76.233] (snvvpn2-10-72-76-c233.corp.yahoo.com [10.72.76.233]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8HHBrC0091523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Sep 2006 10:11:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=1GOF3wyBL3ukHeWt2e0VWJaSVsorgAJUJT2tIBFvlOasxoJ5VSSXRLlpr8sF1WZc Message-ID: <450D81D7.1070004@yahoo-inc.com> Date: Sun, 17 Sep 2006 10:11:51 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] RFC 4646 production "grandfathered" considered harmful References: <20060917061912.GB26073@ccil.org> In-Reply-To: <20060917061912.GB26073@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Good point. I like the idea of the irregular list. Addison John Cowan wrote: > Section 2.2.9 of RFC 4646 says: > > An implementation that claims to check for well-formed language tags > MUST: > > o Check that the tag and all of its subtags, including extension and > private use subtags, conform to the ABNF OR that the tag is on the > list of grandfathered tags. > > o Check that singleton subtags that identify extensions do not > repeat. For example, the tag "en-a-xx-b-yy-a-zz" is not well- > formed. > > (I have emphasized the word OR in the first bullet point.) > > Unfortunately, this wording allows too much. For example, the invalid tag > "ra-bb-it" matches the "grandfathered" rule in the ABNF. Therefore it > winds up being well-formed even though it cannot be analyzed as a sequence > of subtags and is not on the grandfathered list either. > > To avoid this, we can take one of two actions: > > 1) Remove the "grandfathered" production in the ABNF altogether, and use > the "OR" in the conformance clause to allow the irregular grandfathered > tags (that is, those which don't match the "langtag" or "privateuse" > productions) to be well-formed. The danger here is that people will > implement the ABNF only, and the grandfathered tags will become outright > unusable rather than merely discouraged. > > 2) Add an explicit "irregular" production in place of the "grandfathered" > production which explicitly enumerates the 17 irregular grandfathered > tags, thus: > > 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" > > It is safe to enumerate this list explicitly, as it can neither grow > nor shrink. It's true that all the tags except "i-default" can become > deprecated, but that makes no difference to well-formed processors. > The other grandfathered tags in the registry are all well-formed already > and do not need to be in this list. > > In this case the conformance clause can be simplified by omitting the > second part of the "OR". > > I favor choice 2. > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 13:12:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP0Bn-0006Ld-RJ; Sun, 17 Sep 2006 13:12:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP0Bm-0006LC-Ho for ltru@lists.ietf.org; Sun, 17 Sep 2006 13:12:18 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP0Bl-0005xW-9M for ltru@lists.ietf.org; Sun, 17 Sep 2006 13:12:18 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 8BE8B240814; Sun, 17 Sep 2006 19:12:15 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 0DFEB1185A; Sun, 17 Sep 2006 19:12:07 +0200 (CEST) Date: Sun, 17 Sep 2006 19:12:07 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20060917171207.GA31407@sources.org> References: <450B2F27.FD7@xyzzy.claranet.de> <20060917143445.GA10307@sources.org> <450D6D1E.6AAB@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450D6D1E.6AAB@xyzzy.claranet.de> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: DOCTYPE ltru X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sun, Sep 17, 2006 at 05:43:26PM +0200, Frank Ellermann wrote a message of 36 lines which said: > With a DTD some ABNF details are lost, I've used the name for a hint > about the real type (NMTOKEN isn't very precise for dates ;-) Yes, one more reason to drop DTD (it is the only XML schema language without typing). > > I do not see Preferred-value in your schema? > > It's the optional (#IMPLIED) "tag" in a element. OK, sorry for missing it. > Your RELAXed spec. is Greek to me. Well, if you know DTD and not RelaxNG, I'm not surprised. But people, specially software people, who have no prior experience with either DTD or RelaxNG, often find that RelaxNG is more readable. Anyway, it is probably not a good idea to start a lengthy discussion about the various schema languages for XML (specially since we can have several: some W3C standards work that way, and RFC 2629 has an unofficial RelaxNG schema, as well as the old and official DTD). > That's no problem, but it also won't work as is with a DTD > validator. Of course. And your DTD will not work with a RelaxNG validator either. What's the point? To prove that a Perl script will not run with a Python compiler? :-) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 13:15:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP0EP-0007O1-G7; Sun, 17 Sep 2006 13:15:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP0EO-0007Nu-Vm for ltru@ietf.org; Sun, 17 Sep 2006 13:15:00 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP0EN-0006eD-Kt for ltru@ietf.org; Sun, 17 Sep 2006 13:15:00 -0400 Received: from [10.72.76.233] (snvvpn2-10-72-76-c233.corp.yahoo.com [10.72.76.233]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8HHEnoA091621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Sep 2006 10:14:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=yIpo9hT7MK2SCmI44I8RADbRib1+a4y/byUwBHiahNUgJD6+3Qu3/1ROIOwymxUB Message-ID: <450D8288.5090307@yahoo-inc.com> Date: Sun, 17 Sep 2006 10:14:48 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Re: UTF-8 References: <00ae01c6d9e8$a3deb740$6401a8c0@DGBP7M81> <6.0.0.20.2.20060917154346.08a01070@localhost> In-Reply-To: <6.0.0.20.2.20060917154346.08a01070@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: >> >>>> I'm sure the logistic problems with IANA can be sorted out (e.g. using attachments). >>> Or sending the form in escaped ASCII and telling IANA to unescape it. >> > > Agreed. Yeah, well, or we could give them a set of tools for assembling and validating the file. A UTF-8 checker (I have them in perl, Java, C flavors, etc.) is easy enough to provide. I don't know the details, but there is even a tools site that could host the validator. > >>> I don't see any reason for us to dabble in transfer encodings! >> No, please. > > Of course we shouldn't invent new transfer encodings. > But suggesting to IANA that they also offer the file as > compressed over HTTP should be okay, or not? > Not in the RFC, though, eh? Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 13:19:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP0IJ-0000Na-8P; Sun, 17 Sep 2006 13:19:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP0IH-0000NU-Ta for ltru@lists.ietf.org; Sun, 17 Sep 2006 13:19:01 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP0IE-0008W8-BA for ltru@lists.ietf.org; Sun, 17 Sep 2006 13:19:01 -0400 Received: from [10.72.76.233] (snvvpn2-10-72-76-c233.corp.yahoo.com [10.72.76.233]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8HHIrPe091757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Sep 2006 10:18:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=SRxhyEhSGGILQ6tlWTMmNKJelbA/FVDAgfuA2NFI13d/0wVh3L++UFIk6oaoU9XY Message-ID: <450D837D.40509@yahoo-inc.com> Date: Sun, 17 Sep 2006 10:18:53 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Re: UTF-8 References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> <6.0.0.20.2.20060916114849.081056e0@localhost> <450BD347.9EA@xyzzy.claranet.de> <6.0.0.20.2.20060917154808.08a12880@localhost> In-Reply-To: <6.0.0.20.2.20060917154808.08a12880@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rsmtp2.corp.yahoo.com id k8HHIrPe091757 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org By the way: nothing says we have to put the actual updated registry into=20 the I-D. Yes, we did it that way last time. But that is NOT the only way=20 to transmit data to them. And I purposely selected the text in=20 4646bis-00 to *not* specifically state what form the update would take. I would suggest that it would be just as easy and/or better to specify=20 that the LSTR (via his technical helper, aka Doug) create and verify the=20 updated registry before forwarding it. In fact, I've been thinking about text that Doug could use in 4645bis to=20 manage the interregnum process and I'll send that to the list shortly. Addison Martin Duerst wrote: > At 19:34 06/09/16, Frank Ellermann wrote: >> Martin Duerst wrote: >> >> [UTF-8 registry] >>>> I'm opposed. >>> It would be good to know why. >> ftp://ftp.iana.org/assignments/language-subtag-registry >> >> I've no clue what FTP clients would do with something like >> that. >=20 > Just save the file. If it's transferred as text, things > may go wrong for an EBCDIC system. If transferred as > binary, it will still be UTF-8. >=20 >> John's "net-UTF-8" draft isn't ready, and I had some >> troubles to understand his last published version. >=20 > That isn't very relevant, except that it suggests > normalization to NFC, which I assume we would do anyway, > and which is already an issue in the case of NCRs. >=20 >> Another issue are fonts, for RFC 4646 there were proposals >> to restrict the registry to Latn. >=20 > Bad idea. Any average browser installation has way wider > coverage. >=20 >> Fortunately that was >> dropped, because the problem doen't exist with US-ASCII >> plus NCRs. >> >>> something like Bokmål is just plain annoying. >> At least we know what this is. Bokm=E3=83=86=E3=83=BBl is less clear = - >> raw UTF-8 displayed as Latin-1, http://purl.net/net/ucode/E5 >=20 > Well, and then interpreted as Shift-JIS in the case of my > mailer :-(. Our spec as well as the HTTP headers will say > that it's UTF-8. That should be enough. People who are > okay to see garbage will be as satisfied with Bokmå > as they are with Bokm=E3=83=86=E3=83=BBl, or any other weird rendering, > but people who like to see the real thing will be best > served by UTF-8. >=20 >>> I'm sure the logistic problems with IANA can be sorted >>> out (e.g. using attachments). >> Yes. I doubt that there is any logistic problem for mail >> submissions. Only for the bulk update, the fattest I-D in >> the history of the Internet using B64, they'd shoot us. >=20 > We could define a process experiment. As it is only for > an I-D, not for an RFC, that should work. I have seen > non-ASCII stuff in I-Ds, but checks may be a bit more > strict nowadays. >=20 >> We could try QP, and silently send them Doug's original >> data (as mail) in addition to the I-D. >=20 > If 'them' is IANA, that might work. If 'them' is the > Internet-Drafts Editor, that'd not make sense. >=20 >> We've no clear idea which tools will exist for the 4646 >> format in six months, how they do their updates (http or >> ftp), and what local conversions they use. Doug already >> proposed that an UTF-8 version might have to keep the >> & convention, that could be confusing. >=20 > Yes. I'd agree that '&#x' sequences might need escaping, > but I don't expect any of these. Simple & would be okay > unescaped, it would trigger an error in strictly implemented > RFC 4646 software, the same way as UTF-8, and would not > cause any interpretation problems. >=20 >> And we'd have >> to decide if a signature is required, another change of >> the record-jar ABNF. >=20 > Yes. No signature, please. >=20 >>> compression, this can be done mostly transparently. >>> browsers tell servers what encodings they support, e.g. >>> like so: >>> Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=3D0 >> ACK, I forgot this, my favourite browser uses HTTP/1.0 ;-) >> >> An explicit gzip variant could still make sense for ftp >> and HTTP/1.0 (?) >=20 > Yes. >=20 >> We can add some "IANA might consider to >> offer" blurb in the IANA considerations, but IMO we can't >> tell them how to run their servers. >=20 > Agreed. >=20 >=20 > Regards, Martin. >=20 >=20 >=20 > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.j= p =20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru --=20 Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 13:26:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP0P2-0003Cc-20; Sun, 17 Sep 2006 13:26:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP0P0-0003Bx-NH for ltru@lists.ietf.org; Sun, 17 Sep 2006 13:25:58 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP0Oz-00022e-CU for ltru@lists.ietf.org; Sun, 17 Sep 2006 13:25:58 -0400 Received: from [10.72.76.233] (snvvpn2-10-72-76-c233.corp.yahoo.com [10.72.76.233]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8HHPn1j091983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Sep 2006 10:25:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=klNCOY13751r2lvTBgIBRNIpbvB9yX6lyNnecIRiC19D6BTvrJewF4VI1xaaVnxO Message-ID: <450D851D.5020705@yahoo-inc.com> Date: Sun, 17 Sep 2006 10:25:49 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] record-jar References: <008801c6d9b3$da4b9e40$6401a8c0@DGBP7M81> <450C3C87.8030904@yahoo-inc.com> <450D3532.59A9@xyzzy.claranet.de> In-Reply-To: <450D3532.59A9@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > >>> What is "modified" about the Registry's format as compared >>> to "standard" record-jar? > >> Since there ain't no such beast as "standard record-jar", >> nothing. > > Does the original record-jar allow comments introduced by % ? > For "original" = as published in the [record-jar] reference. > Looking into your updated draft, you have %% comment, and > some backslash magic, that's "modified" wrt RFC 4646. > Art of Unix Programming [AOUP] doesn't say. I introduced comments in draft-record-jar because I think they were a stupid decision on our part in 4646--and note that AOUP endorses (strongly recommends) a comment syntax. My draft is modified vs. 4646, although currently 4646 modifies the syntax by regulating (prohibiting) certain record-jar features in my draft. So.... 4646 is "modified" record-jar by that, unpublished, measure. On the other hand, AOUP isn't specific enough to know whether 4646 is modified or not. :-) Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 13:27:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP0Qu-0003kS-H6; Sun, 17 Sep 2006 13:27:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP0Qt-0003kH-BK for ltru@lists.ietf.org; Sun, 17 Sep 2006 13:27:55 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP0Qr-0002e9-Vs for ltru@lists.ietf.org; Sun, 17 Sep 2006 13:27:55 -0400 Received: from [10.72.76.233] (snvvpn2-10-72-76-c233.corp.yahoo.com [10.72.76.233]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8HHRcUk095316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Sep 2006 10:27:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=HLfmzTc7/r3/SewHsxwnux+AW23tabXNt9Lwx1yeMZozwbuM9vo55Afuguswf0g/ Message-ID: <450D858A.9030605@yahoo-inc.com> Date: Sun, 17 Sep 2006 10:27:38 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: DOCTYPE ltru References: <008201c6d9b2$ebfd2600$6401a8c0@DGBP7M81> <450D3691.75B0@xyzzy.claranet.de> In-Reply-To: <450D3691.75B0@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Capitalization doesn't mean anything in language tags and never has. We should fix it in the registry (via the reg process if possible, but certainly via 4645bis if not) Addison Frank Ellermann wrote: > Doug Ewell wrote: > >>> with XML ID _latn is not _Latn. > >> It's capitalized that way because it was registered that way >> under RFC 3066. > > Could we add this oddity as another exception (like zh-min) to > 4645bis, or is it more straight forward if I try to update it > directly using the language list ? > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 14:38:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP1X9-00033G-Bi; Sun, 17 Sep 2006 14:38:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP1X7-00033B-Fi for ltru@ietf.org; Sun, 17 Sep 2006 14:38:25 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP1X6-0001fR-93 for ltru@ietf.org; Sun, 17 Sep 2006 14:38:25 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GP1X3-00048K-MV; Sun, 17 Sep 2006 14:38:21 -0400 Date: Sun, 17 Sep 2006 14:38:21 -0400 To: Martin Duerst Subject: Re: [Ltru] Re: UTF-8 Message-ID: <20060917183821.GC26073@ccil.org> References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> <6.0.0.20.2.20060916114849.081056e0@localhost> <450BD347.9EA@xyzzy.claranet.de> <6.0.0.20.2.20060917154808.08a12880@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060917154808.08a12880@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > Well, and then interpreted as Shift-JIS in the case of my > mailer :-(. Our spec as well as the HTTP headers will say > that it's UTF-8. That should be enough. People who are > okay to see garbage will be as satisfied with Bokmå > as they are with Bokm?$B%F!&l, or any other weird rendering, > but people who like to see the real thing will be best > served by UTF-8. Bokmål is at least reconstructible without knowing anything except the SGML character reference conventions and the codepoints of Unicode characters; Bokm?$B%F!&l (which is the way it got to me, sans ESC characters) is nothing but rubbish. This is an *excellent* example of why we need explicit escaping (for which SGML is as good a convention as any) rather than encoding, given the present state of email. -- John Cowan cowan@ccil.org http://ccil.org/~cowan In the sciences, we are now uniquely privileged to sit side by side with the giants on whose shoulders we stand. --Gerald Holton _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 15:12:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP23u-0006qJ-Bc; Sun, 17 Sep 2006 15:12:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP23t-0006q9-Gr for ltru@lists.ietf.org; Sun, 17 Sep 2006 15:12:17 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP23s-000772-8k for ltru@lists.ietf.org; Sun, 17 Sep 2006 15:12:17 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id EB1D4240814; Sun, 17 Sep 2006 21:12:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id F198B131AF; Sun, 17 Sep 2006 21:09:40 +0200 (CEST) Date: Sun, 17 Sep 2006 21:09:40 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20060917190940.GA17105@sources.org> References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <6.0.0.20.2.20060915154910.06e040b0@localhost> <450AC979.3050203@yahoo-inc.com> <450B60D4.1040401@sil.org> <450B8272.52B2@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450B8272.52B2@xyzzy.claranet.de> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: script tag for IPA X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sat, Sep 16, 2006 at 06:49:54AM +0200, Frank Ellermann wrote a message of 68 lines which said: > It would also break a main feature of 4646, minus grandfathered > cruft you can decompose a tag into subtags, and you always know what > each subtag is if you keep the leading hyphen: -1234 => must be a > variant, -abcd => must be a script, -123 => must be an UN M.49 > number, -ab => must be a 3166 CC, -abc => extlang, abc => language, > ab => language, abcd => language (not yet possible), etc. I do not believe it is true. In "fr-x-abcd", "-abcd" is not a script. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 15:32:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP2Nn-0005ro-2r; Sun, 17 Sep 2006 15:32:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP2Nl-0005pK-3l for ltru@ietf.org; Sun, 17 Sep 2006 15:32:49 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP2Nj-0002Km-OV for ltru@ietf.org; Sun, 17 Sep 2006 15:32:49 -0400 Received: from [10.72.76.233] (snvvpn2-10-72-76-c233.corp.yahoo.com [10.72.76.233]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8HJWXG4099519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Sep 2006 12:32:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=bEqzrBhOFX5I71EdC/fiA8CyjtYTejCaHyV6NQjY0O2lpzFrwH/TYFjcN6bJurKs Message-ID: <450DA2D1.6020706@yahoo-inc.com> Date: Sun, 17 Sep 2006 12:32:33 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Re: UTF-8 References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> <6.0.0.20.2.20060916114849.081056e0@localhost> <450BD347.9EA@xyzzy.claranet.de> <6.0.0.20.2.20060917154808.08a12880@localhost> <20060917183821.GC26073@ccil.org> In-Reply-To: <20060917183821.GC26073@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > >> Well, and then interpreted as Shift-JIS in the case of my >> mailer :-(. Our spec as well as the HTTP headers will say >> that it's UTF-8. That should be enough. People who are >> okay to see garbage will be as satisfied with Bokmå >> as they are with Bokm?$B%F!&l, or any other weird rendering, >> but people who like to see the real thing will be best >> served by UTF-8. > > Bokmål is at least reconstructible without knowing anything > except the SGML character reference conventions and the > codepoints of Unicode characters; Bokm?$B%F!&l (which is the > way it got to me, sans ESC characters) is nothing but rubbish. Well, that's mozibake: it's ISO 2022-JP encoding of the Shift-JIS characters made by mis-interpreting UTF-8 bytes. Lovely. > > This is an *excellent* example of why we need explicit escaping > (for which SGML is as good a convention as any) rather than > encoding, given the present state of email. > But that consideration doesn't apply to the registry file. It only applies to the discussion of a registry entry on ietf-languages. Admittedly MUAs vary greatly in their support for encodings, but we can certainly specify directions for how to send the registration request to the list so that everyone can tell what code points are intended and other instructions for how to encode those characters in the registry. Suggestions to limit the character repertoire strike me as counter productive too. Why would we do that? I could see, for example, that we might end up with a few Chinese descriptions or comments in the registry to disambiguate Chinese variations. Why artificially restrict it 'ab initio'? I find this fascination with ASCII slightly quaint. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 16:07:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP2un-0000xx-F9; Sun, 17 Sep 2006 16:06:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP2um-0000xs-09 for ltru@ietf.org; Sun, 17 Sep 2006 16:06:56 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP2uj-0002Rb-QD for ltru@ietf.org; Sun, 17 Sep 2006 16:06:55 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GP2uj-0006PD-Gk; Sun, 17 Sep 2006 16:06:53 -0400 Date: Sun, 17 Sep 2006 16:06:53 -0400 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: script tag for IPA Message-ID: <20060917200653.GE26073@ccil.org> References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <6.0.0.20.2.20060915154910.06e040b0@localhost> <450AC979.3050203@yahoo-inc.com> <450B60D4.1040401@sil.org> <450B8272.52B2@xyzzy.claranet.de> <20060917190940.GA17105@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060917190940.GA17105@sources.org> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer scripsit: > I do not believe it is true. In "fr-x-abcd", "-abcd" is not a script. Well, it's true if you deal with private-use and extension subtags first. -- LEAR: Dost thou call me fool, boy? John Cowan FOOL: All thy other titles http://www.ccil.org/~cowan thou hast given away: cowan@ccil.org That thou wast born with. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 17:13:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP3xF-0000Nz-R7; Sun, 17 Sep 2006 17:13:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP3xE-0000M9-1y for ltru@ietf.org; Sun, 17 Sep 2006 17:13:32 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP3pC-0008Kp-JG for ltru@ietf.org; Sun, 17 Sep 2006 17:05:15 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GP3pB-0000NM-Gh; Sun, 17 Sep 2006 17:05:13 -0400 Date: Sun, 17 Sep 2006 17:05:13 -0400 To: Addison Phillips Subject: Re: [Ltru] Re: UTF-8 Message-ID: <20060917210513.GF26073@ccil.org> References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> <6.0.0.20.2.20060916114849.081056e0@localhost> <450BD347.9EA@xyzzy.claranet.de> <6.0.0.20.2.20060917154808.08a12880@localhost> <20060917183821.GC26073@ccil.org> <450DA2D1.6020706@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450DA2D1.6020706@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > >Bokm?$B%F!&l (which is the > >way it got to me, sans ESC characters) is nothing but rubbish. > > Well, that's mozibake: it's ISO 2022-JP encoding of the Shift-JIS > characters made by mis-interpreting UTF-8 bytes. Lovely. Not even. My mailer suppresses ESC characters altogether, so the result is pure printable ASCII again, ergo unreconstructible. > But that consideration doesn't apply to the registry file. It only > applies to the discussion of a registry entry on ietf-languages. > Admittedly MUAs vary greatly in their support for encodings, but we can > certainly specify directions for how to send the registration request to > the list so that everyone can tell what code points are intended and > other instructions for how to encode those characters in the registry. Directions which work uniformly across all native encodings, operating environments, and mailers? I venture to doubt it. > Suggestions to limit the character repertoire strike me as counter > productive too. +1 -- John Cowan cowan@ccil.org http://ccil.org/~cowan In the sciences, we are now uniquely privileged to sit side by side with the giants on whose shoulders we stand. --Gerald Holton _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 17:49:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP4Vj-0004p1-BM; Sun, 17 Sep 2006 17:49:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP4Vh-0004ou-Ix for ltru@lists.ietf.org; Sun, 17 Sep 2006 17:49:09 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP4Vb-0000jr-VC for ltru@lists.ietf.org; Sun, 17 Sep 2006 17:49:09 -0400 Received: by nf-out-0910.google.com with SMTP id n15so2911115nfc for ; Sun, 17 Sep 2006 14:49:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=N5hW8j4MkV1cUonpAjXHGlwQnd0wXsYDtmmkXK41kvHSAdFxNumrFmTwzwctJnBeMduaL7NIWIVWNqOdk0oydR8Kq8m3SGjALIVklXtOC7ISqH2h+D5Looi/yPlNdHw4T0EINQUaNMxE0otZvxfEpCZUf00svmfz4GYwWQEoHVE= Received: by 10.48.14.4 with SMTP id 4mr16244310nfn; Sun, 17 Sep 2006 14:49:01 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Sun, 17 Sep 2006 14:49:01 -0700 (PDT) Message-ID: <30b660a20609171449u1ee4b3b9n9c715666aa369226@mail.gmail.com> Date: Sun, 17 Sep 2006 14:49:01 -0700 From: "Mark Davis" To: "Martin Duerst" Subject: Re: [Ltru] Re: Test suite for language tags? In-Reply-To: <6.0.0.20.2.20060917115535.0899d670@localhost> MIME-Version: 1.0 References: <20060801203351.GA8854@sources.org> <20060804165720.GA24037@sources.org> <44D4AC42.79E0@xyzzy.claranet.de> <20060830093000.GA31895@nic.fr> <44F6313D.2070000@yahoo-inc.com> <6.0.0.20.2.20060831201004.101ab8d0@localhost> <44F6EF0E.20602@yahoo-inc.com> <6.0.0.20.2.20060901024806.109a6d90@localhost> <30b660a20609161628t22ab3c4flc81ea92f40800a09@mail.gmail.com> <6.0.0.20.2.20060917115535.0899d670@localhost> X-Google-Sender-Auth: a8a8f3037ff56768 X-Spam-Score: 0.5 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1724309798==" Errors-To: ltru-bounces@ietf.org --===============1724309798== Content-Type: multipart/alternative; boundary="----=_Part_165882_25949601.1158529741215" ------=_Part_165882_25949601.1158529741215 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Fixed, thanks! Mark On 9/16/06, Martin Duerst wrote: > > There's a mistake in the regex, from the underlying > langtagRegex.txt, that allows zh-zh-cmn-Hans. > > Regards, Martin. > > > At 08:28 06/09/17, Mark Davis wrote: > >BTW, I had updated my regex to the final spec for 4646. Here is a single > Perl or Java regex that does most of the parse: > > > >Regex: ((?: [a-z A-Z]{2,3} (?: [-] [a-z A-Z]{3} ){0,3} | [a-z A-Z]{4,8} > ))(?: [-] ((?: [a-z A-Z]{4} )) )?(?: [-] ((?: [a-z A-Z]{2} | [0-9]{3} )) > )?(?: [-] ((?: (?: [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) (?: [-] (?: > [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) )* )) )?(?: [-] ((?: (?: [a-w > y-z A-W Y-Z] (?: [-] [a-z A-Z 0-9]{2,8} )+ ) (?: [-] (?: [a-w y-z A-W Y-Z] > (?: [-] [a-z A-Z 0-9]{2,8} )+ ) )* )) )?(?: [-] ((?: [xX] (?: [-] [a-z A-Z > 0-9]{1,8} )+ )) )?| ( (?i) art [-] lojban| cel [-] gaulish| en [-] (?: boont > | GB [-] oed | scouse )| i [-] (?: ami | bnn | default | enochian | hak | > klingon | lux | mingo | navajo | pwn | tao | tay | tsu )| no [-] (?: bok | > nyn)| sgn [-] (?: BE [-] fr | BE [-] nl | CH [-] de)| zh [-] (?: cmn | zh > [-] cmn [-] Hans | cmn [-] Hant | gan | guoyu | hakka | min | min [-] nan | > wuu | xiang | yue))| ((?: [xX] (?: [-] [a-z A-Z 0-9]{1,8} )+ )) > > > >It checks for the grandfathered tags, since otherwise too much cruft > sneaks in. You can't check in regex that there are only single instances of > each singleton extension. (In retrospect we could have allowed multiple > singletons: we could have accepted en-a-bcdef-ghijk-b-123 -a-lmnop as > equivalent to the canonical form en-a-bcdef-ghijk-lmnop-b-123, but that's > water under the bridge at this point.) Of course, I didn't put this together > by hand. The table used to build it is much more readable, at > > > >< > http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagRegex.txt > > > http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagRegex.txt > > > >and a test file that includes strings mentioned on this list is at: > > > >< > http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagTest.txt > > > http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagTest.txt > >Mark > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > ------=_Part_165882_25949601.1158529741215 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Fixed, thanks!

Mark

On 9/16/06, Martin Duerst <duerst@it.aoyama.ac.jp> wrote:
There's a mistake in the regex, from the underlying
langtagRegex.txt, that allows zh-zh-cmn-Hans.

Regards,    Martin.


At 08:28 06/09/17, Mark Davis wrote:
>BTW, I had updated my regex to the final spec for 4646. Here is a single Perl or Java regex that does most of the parse:
>
>Regex: ((?: [a-z A-Z]{2,3} (?: [-] [a-z A-Z]{3} ){0,3} | [a-z A-Z]{4,8} ))(?: [-] ((?: [a-z A-Z]{4} )) )?(?: [-] ((?: [a-z A-Z]{2} | [0-9]{3} )) )?(?: [-] ((?: (?: [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) (?: [-] (?: [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) )* )) )?(?: [-] ((?: (?: [a-w y-z A-W Y-Z] (?: [-] [a-z A-Z 0-9]{2,8} )+ ) (?: [-] (?: [a-w y-z A-W Y-Z] (?: [-] [a-z A-Z 0-9]{2,8} )+ ) )* )) )?(?: [-] ((?: [xX] (?: [-] [a-z A-Z 0-9]{1,8} )+ )) )?| ( (?i) art [-] lojban| cel [-] gaulish| en [-] (?: boont | GB [-] oed | scouse )| i [-] (?: ami | bnn | default | enochian | hak | klingon | lux | mingo | navajo | pwn | tao | tay | tsu )| no [-] (?: bok | nyn)| sgn [-] (?: BE [-] fr | BE [-] nl | CH [-] de)| zh [-] (?: cmn | zh [-] cmn [-] Hans | cmn [-] Hant | gan | guoyu | hakka | min | min [-] nan | wuu | xiang | yue))| ((?: [xX] (?: [-] [a-z A-Z 0-9]{1,8} )+ ))
>
>It checks for the grandfathered tags, since otherwise too much cruft sneaks in. You can't check in regex that there are only single instances of each singleton extension. (In retrospect we could have allowed multiple singletons: we could have accepted en-a-bcdef-ghijk-b-123 -a-lmnop as equivalent to the canonical form en-a-bcdef-ghijk-lmnop-b-123, but that's water under the bridge at this point.) Of course, I didn't put this together by hand. The table used to build it is much more readable, at
>
><http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagRegex.txt> http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagRegex.txt
>
>and a test file that includes strings mentioned on this list is at:
>
>< http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagTest.txt>http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagTest.txt
>Mark


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


------=_Part_165882_25949601.1158529741215-- --===============1724309798== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1724309798==-- From ltru-bounces@ietf.org Sun Sep 17 17:54:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP4b3-0006XC-0A; Sun, 17 Sep 2006 17:54:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP4b1-0006X7-Lo for ltru@lists.ietf.org; Sun, 17 Sep 2006 17:54:39 -0400 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP4b0-0001sS-8x for ltru@lists.ietf.org; Sun, 17 Sep 2006 17:54:39 -0400 Received: by nf-out-0910.google.com with SMTP id n15so2911788nfc for ; Sun, 17 Sep 2006 14:54:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=N5SlXOgWNgIiY9Z/qgy9MPuu8MtbcU4dHJRvt4e5QsMJAVJmGHoeBW/jOqNuX6jzumg9RJu58awnNxL0GZjAXSJFM9CPsXhdoaOz5IY1N61JdIxY8/mT5vGz26zNA7bBFFrK4+4rug3rUMCACbYNfamdeMUf2Xg5ilXvmsmUvD0= Received: by 10.48.254.1 with SMTP id b1mr16261607nfi; Sun, 17 Sep 2006 14:54:36 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Sun, 17 Sep 2006 14:54:36 -0700 (PDT) Message-ID: <30b660a20609171454k3f80374p646d156948c13535@mail.gmail.com> Date: Sun, 17 Sep 2006 14:54:36 -0700 From: "Mark Davis" To: "Stephane Bortzmeyer" In-Reply-To: <20060917165050.GA29413@sources.org> MIME-Version: 1.0 References: <20060802072709.GA17404@nic.fr> <20060804165720.GA24037@sources.org> <44D4AC42.79E0@xyzzy.claranet.de> <20060830093000.GA31895@nic.fr> <44F6313D.2070000@yahoo-inc.com> <6.0.0.20.2.20060831201004.101ab8d0@localhost> <44F6EF0E.20602@yahoo-inc.com> <6.0.0.20.2.20060901024806.109a6d90@localhost> <30b660a20609161628t22ab3c4flc81ea92f40800a09@mail.gmail.com> <20060917165050.GA29413@sources.org> X-Google-Sender-Auth: 554d6793c55b6b8f X-Spam-Score: 0.5 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ltru@lists.ietf.org Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0081637701==" Errors-To: ltru-bounces@ietf.org --===============0081637701== Content-Type: multipart/alternative; boundary="----=_Part_165954_10114451.1158530076639" ------=_Part_165954_10114451.1158530076639 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline That's odd. Testing in Java on the file http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagTest.txt(which includes those cases) the only failures I get are the ones that repeat extensions (like en-a-bbb-a-ccc), which can't be tested for with regex. I don't think I'm using any regex syntax that differs between Java and Perl (there are very few instances). Note: I added a number of mechanically generated items to the test file. Mark On 9/17/06, Stephane Bortzmeyer wrote: > > On Sat, Sep 16, 2006 at 04:28:01PM -0700, > Mark Davis wrote > a message of 98 lines which said: > > > BTW, I had updated my regex to the final spec for 4646. Here is a > > single Perl or Java regex that does most of the parse: > > Isn't it too lax? When testing it in a Perl script, I find it accepts > all my well-formed tags (OK) but also accepts wrongly: > > fr-Latn-F is well-formed > en-a-bbb-a-ccc is well-formed > tlh-a-b-foo is well-formed > abcdefghi-012345678 is well-formed > ab-abc-abc-abc-abc is well-formed > ab-abcd-abc is well-formed > ab-ab-abc is well-formed > ab-123-abc is well-formed > ab-abcde-abc is well-formed > ab-1abc-abc is well-formed > ab-ab-abcd is well-formed > ab-123-abcd is well-formed > ab-abcde-abcd is well-formed > ab-1abc-abcd is well-formed > ab-a-b is well-formed > ab-a-x is well-formed > ab--ab is well-formed > ab-abc- is well-formed > ab-c-abc-r-toto-c-abc is well-formed > abcd-efg is well-formed > aabbccddE is well-formed > ------=_Part_165954_10114451.1158530076639 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline That's odd. Testing in Java on the file http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagTest.txt (which includes those cases) the only failures I get are the ones that repeat extensions (like en-a-bbb-a-ccc), which can't be tested for with regex. I don't think I'm using any regex syntax that differs between Java and Perl (there are very few instances).

Note: I added a number of mechanically generated items to the test file.

Mark

On 9/17/06, Stephane Bortzmeyer < bortzmeyer@nic.fr> wrote:
On Sat, Sep 16, 2006 at 04:28:01PM -0700,
Mark Davis < mark.davis@icu-project.org> wrote
a message of 98 lines which said:

> BTW, I had updated my regex to the final spec for 4646. Here is a
> single Perl or Java regex that does most of the parse:

Isn't it too lax? When testing it in a Perl script, I find it accepts
all my well-formed tags (OK) but also accepts wrongly:

fr-Latn-F is well-formed
en-a-bbb-a-ccc is well-formed
tlh-a-b-foo is well-formed
abcdefghi-012345678 is well-formed
ab-abc-abc-abc-abc is well-formed
ab-abcd-abc is well-formed
ab-ab-abc is well-formed
ab-123-abc is well-formed
ab-abcde-abc is well-formed
ab-1abc-abc is well-formed
ab-ab-abcd is well-formed
ab-123-abcd is well-formed
ab-abcde-abcd is well-formed
ab-1abc-abcd is well-formed
ab-a-b is well-formed
ab-a-x is well-formed
ab--ab is well-formed
ab-abc- is well-formed
ab-c-abc-r-toto-c-abc is well-formed
abcd-efg is well-formed
aabbccddE is well-formed

------=_Part_165954_10114451.1158530076639-- --===============0081637701== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0081637701==-- From ltru-bounces@ietf.org Sun Sep 17 17:57:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP4dn-0007cS-K9; Sun, 17 Sep 2006 17:57:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP4dm-0007cM-Mo for ltru@lists.ietf.org; Sun, 17 Sep 2006 17:57:30 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP4dm-0002Vb-3c for ltru@lists.ietf.org; Sun, 17 Sep 2006 17:57:30 -0400 Received: by nf-out-0910.google.com with SMTP id n15so2912133nfc for ; Sun, 17 Sep 2006 14:57:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=RjwH7cq9RZYkN3GUwlnty/eJZ2NsG76fMmEaxDq+oZYmaPXajIx/+M8yO9x4CD1LjWPTK04OH6Ou+CINQpfrQp3ZnDdbbGQAmJZhK0YQT/YcVSPuQcxg+vxj3gX7f6xt1/ZmrKE3CcJlV0aqK9gP1roxyv4ey569qTur2hD6qL4= Received: by 10.48.162.15 with SMTP id k15mr16266957nfe; Sun, 17 Sep 2006 14:57:29 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Sun, 17 Sep 2006 14:57:28 -0700 (PDT) Message-ID: <30b660a20609171457j5eb18ba2t60b43c5389b474d0@mail.gmail.com> Date: Sun, 17 Sep 2006 14:57:28 -0700 From: "Mark Davis" To: "Stephane Bortzmeyer" In-Reply-To: <30b660a20609171454k3f80374p646d156948c13535@mail.gmail.com> MIME-Version: 1.0 References: <20060802072709.GA17404@nic.fr> <44D4AC42.79E0@xyzzy.claranet.de> <20060830093000.GA31895@nic.fr> <44F6313D.2070000@yahoo-inc.com> <6.0.0.20.2.20060831201004.101ab8d0@localhost> <44F6EF0E.20602@yahoo-inc.com> <6.0.0.20.2.20060901024806.109a6d90@localhost> <30b660a20609161628t22ab3c4flc81ea92f40800a09@mail.gmail.com> <20060917165050.GA29413@sources.org> <30b660a20609171454k3f80374p646d156948c13535@mail.gmail.com> X-Google-Sender-Auth: a63106174790a155 X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1221598826==" Errors-To: ltru-bounces@ietf.org --===============1221598826== Content-Type: multipart/alternative; boundary="----=_Part_165994_15856756.1158530248660" ------=_Part_165994_15856756.1158530248660 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline BTW, here is the regex with the fix for the problem that Martin noticed, and also restricted to the irregular grandfathered codes. (?: ((?: [a-z A-Z]{2,3} (?: [-] [a-z A-Z]{3} ){0,3} | [a-z A-Z]{4,8} ))(?: [-] ((?: [a-z A-Z]{4} )) )? (?: [-] ((?: [a-z A-Z]{2} | [0-9]{3} )) )? (?: [-] ((?: (?: [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) (?: [-] (?: [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) )* )) )? (?: [-] ((?: (?: [a-w y-z A-W Y-Z] (?: [-] [a-z A-Z 0-9]{2,8} )+ ) (?: [-] (?: [a-w y-z A-W Y-Z] (?: [-] [a-z A-Z 0-9]{2,8} )+ ) )* )) )? (?: [-] ((?: [xX] (?: [-] [a-z A-Z 0-9]{1,8} )+ )) )? ) | ((?: (?i)en [-] GB [-] oed| i [-] (?: ami | bnn | default | enochian | hak | klingon | lux | mingo | navajo | pwn | tao | tay | tsu )| sgn [-] (?: BE [-] fr | BE [-] nl | CH [-] de))) | ((?: [xX] (?: [-] [a-z A-Z 0-9]{1,8} )+ )) Mark On 9/17/06, Mark Davis wrote: > > That's odd. Testing in Java on the file > http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagTest.txt(which includes those cases) the only failures I get are the ones that > repeat extensions (like en-a-bbb-a-ccc), which can't be tested for with > regex. I don't think I'm using any regex syntax that differs between Java > and Perl (there are very few instances). > > Note: I added a number of mechanically generated items to the test file. > > Mark > > > On 9/17/06, Stephane Bortzmeyer < bortzmeyer@nic.fr> wrote: > > > > On Sat, Sep 16, 2006 at 04:28:01PM -0700, > > Mark Davis < mark.davis@icu-project.org> wrote > > a message of 98 lines which said: > > > > > BTW, I had updated my regex to the final spec for 4646. Here is a > > > single Perl or Java regex that does most of the parse: > > > > Isn't it too lax? When testing it in a Perl script, I find it accepts > > all my well-formed tags (OK) but also accepts wrongly: > > > > fr-Latn-F is well-formed > > en-a-bbb-a-ccc is well-formed > > tlh-a-b-foo is well-formed > > abcdefghi-012345678 is well-formed > > ab-abc-abc-abc-abc is well-formed > > ab-abcd-abc is well-formed > > ab-ab-abc is well-formed > > ab-123-abc is well-formed > > ab-abcde-abc is well-formed > > ab-1abc-abc is well-formed > > ab-ab-abcd is well-formed > > ab-123-abcd is well-formed > > ab-abcde-abcd is well-formed > > ab-1abc-abcd is well-formed > > ab-a-b is well-formed > > ab-a-x is well-formed > > ab--ab is well-formed > > ab-abc- is well-formed > > ab-c-abc-r-toto-c-abc is well-formed > > abcd-efg is well-formed > > aabbccddE is well-formed > > > > ------=_Part_165994_15856756.1158530248660 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline BTW, here is the regex with the fix for the problem that Martin noticed, and also restricted to the irregular grandfathered codes.

(?: ((?: [a-z A-Z]{2,3} (?: [-] [a-z A-Z]{3} ){0,3} | [a-z A-Z]{4,8} ))(?: [-] ((?: [a-z A-Z]{4} )) )? (?: [-] ((?: [a-z A-Z]{2} | [0-9]{3} )) )? (?: [-] ((?: (?: [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) (?: [-] (?: [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) )* )) )? (?: [-] ((?: (?: [a-w y-z A-W Y-Z] (?: [-] [a-z A-Z 0-9]{2,8} )+ ) (?: [-] (?: [a-w y-z A-W Y-Z] (?: [-] [a-z A-Z 0-9]{2,8} )+ ) )* )) )? (?: [-] ((?: [xX] (?: [-] [a-z A-Z 0-9]{1,8} )+ )) )?  ) |    ((?: (?i)en [-] GB [-] oed|    i [-] (?: ami | bnn | default | enochian | hak | klingon | lux | mingo | navajo | pwn | tao | tay | tsu )|    sgn [-] (?: BE [-] fr | BE [-] nl | CH [-] de))) |    ((?: [xX] (?: [-] [a-z A-Z 0-9]{1,8} )+ ))

Mark

On 9/17/06, Mark Davis <mark.davis@icu-project.org> wrote:
That's odd. Testing in Java on the file http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagTest.txt (which includes those cases) the only failures I get are the ones that repeat extensions (like en-a-bbb-a-ccc), which can't be tested for with regex. I don't think I'm using any regex syntax that differs between Java and Perl (there are very few instances).

Note: I added a number of mechanically generated items to the test file.

Mark


On 9/17/06, Stephane Bortzmeyer < bortzmeyer@nic.fr> wrote:
On Sat, Sep 16, 2006 at 04:28:01PM -0700,
Mark Davis < mark.davis@icu-project.org> wrote
a message of 98 lines which said:

> BTW, I had updated my regex to the final spec for 4646. Here is a
> single Perl or Java regex that does most of the parse:

Isn't it too lax? When testing it in a Perl script, I find it accepts
all my well-formed tags (OK) but also accepts wrongly:

fr-Latn-F is well-formed
en-a-bbb-a-ccc is well-formed
tlh-a-b-foo is well-formed
abcdefghi-012345678 is well-formed
ab-abc-abc-abc-abc is well-formed
ab-abcd-abc is well-formed
ab-ab-abc is well-formed
ab-123-abc is well-formed
ab-abcde-abc is well-formed
ab-1abc-abc is well-formed
ab-ab-abcd is well-formed
ab-123-abcd is well-formed
ab-abcde-abcd is well-formed
ab-1abc-abcd is well-formed
ab-a-b is well-formed
ab-a-x is well-formed
ab--ab is well-formed
ab-abc- is well-formed
ab-c-abc-r-toto-c-abc is well-formed
abcd-efg is well-formed
aabbccddE is well-formed


------=_Part_165994_15856756.1158530248660-- --===============1221598826== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1221598826==-- From ltru-bounces@ietf.org Sun Sep 17 18:09:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP4ow-0002zO-D5; Sun, 17 Sep 2006 18:09:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP4ou-0002zJ-NO for ltru@ietf.org; Sun, 17 Sep 2006 18:09:00 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP4ou-0006Xw-3P for ltru@ietf.org; Sun, 17 Sep 2006 18:09:00 -0400 Received: by nf-out-0910.google.com with SMTP id n15so2913344nfc for ; Sun, 17 Sep 2006 15:08:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=neNlb9URhK3ZBoAIodKcUlS5FDHDFIWR0TVid/QaeQWmhneiDp9GqVkW9D9PSWWJdZrxiATikxKt2yTpEHJCH6ok/GULFfYfpJL1JbG5J1oLCV/Mqa1ZVn+SV/3FWcmt4HmSdsZA1cnme5L3jiLHJs5EniSLU2C/y3YM2Ue+oRI= Received: by 10.48.48.18 with SMTP id v18mr16271088nfv; Sun, 17 Sep 2006 15:08:58 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Sun, 17 Sep 2006 15:08:58 -0700 (PDT) Message-ID: <30b660a20609171508s36585ea5r2311f0ac4c3cb2fe@mail.gmail.com> Date: Sun, 17 Sep 2006 15:08:58 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] RFC 4646 production "grandfathered" considered harmful In-Reply-To: <450D81D7.1070004@yahoo-inc.com> MIME-Version: 1.0 References: <20060917061912.GB26073@ccil.org> <450D81D7.1070004@yahoo-inc.com> X-Google-Sender-Auth: 7ff881232899fede X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0456100698==" Errors-To: ltru-bounces@ietf.org --===============0456100698== Content-Type: multipart/alternative; boundary="----=_Part_166130_8520362.1158530938593" ------=_Part_166130_8520362.1158530938593 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I do as well. Note that the BNF provides both checks of well-formedness (partial, because of repeating extensions), but also a division into semantic units. So we'd have to do something like: grandfathered = irregular / 1*3ALPHA 1*2("-" (2*8alphanum)) ; registered grandfathered codes that are well-formed, but would not otherwise be valid 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" We could also break them down into other divisions ;-) grandfathered = "i-" irregular / irregularEverson / 1*3ALPHA 1*2("-" (2*8alphanum)) ; registered grandfathered codes that are well-formed, but would not otherwise be valid irregulari = "ami" / "bnn" / "default" / "enochian" / "hak" / "klingon" / "lux" / "mingo" / "navajo" / "pwn" / "tao" / "tay" / "tsu" irregularEverson = "en-GB-oed" / "sgn-BE-fr" / "sgn-BE-nl" / "sgn-CH-de" Mark On 9/17/06, Addison Phillips wrote: > > Good point. I like the idea of the irregular list. > > Addison > > John Cowan wrote: > > Section 2.2.9 of RFC 4646 says: > > > > An implementation that claims to check for well-formed language tags > > MUST: > > > > o Check that the tag and all of its subtags, including extension and > > private use subtags, conform to the ABNF OR that the tag is on the > > list of grandfathered tags. > > > > o Check that singleton subtags that identify extensions do not > > repeat. For example, the tag "en-a-xx-b-yy-a-zz" is not well- > > formed. > > > > (I have emphasized the word OR in the first bullet point.) > > > > Unfortunately, this wording allows too much. For example, the invalid > tag > > "ra-bb-it" matches the "grandfathered" rule in the ABNF. Therefore it > > winds up being well-formed even though it cannot be analyzed as a > sequence > > of subtags and is not on the grandfathered list either. > > > > To avoid this, we can take one of two actions: > > > > 1) Remove the "grandfathered" production in the ABNF altogether, and use > > the "OR" in the conformance clause to allow the irregular grandfathered > > tags (that is, those which don't match the "langtag" or "privateuse" > > productions) to be well-formed. The danger here is that people will > > implement the ABNF only, and the grandfathered tags will become outright > > unusable rather than merely discouraged. > > > > 2) Add an explicit "irregular" production in place of the > "grandfathered" > > production which explicitly enumerates the 17 irregular grandfathered > > tags, thus: > > > > 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" > > > > It is safe to enumerate this list explicitly, as it can neither grow > > nor shrink. It's true that all the tags except "i-default" can become > > deprecated, but that makes no difference to well-formed processors. > > The other grandfathered tags in the registry are all well-formed already > > and do not need to be in this list. > > > > In this case the conformance clause can be simplified by omitting the > > second part of the "OR". > > > > I favor choice 2. > > > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_166130_8520362.1158530938593 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I do as well. Note that the BNF provides both checks of well-formedness (partial, because of repeating extensions), but also a division into semantic units. So we'd have to do something like:

grandfathered = irregular 

            / 1*3ALPHA 1*2("-" (2*8alphanum)) ; registered grandfathered codes that are well-formed, but would not otherwise be valid
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"

We could also break them down into other divisions ;-)

grandfathered = "i-" irregular
            / irregularEverson

            / 1*3ALPHA 1*2("-" (2*8alphanum)) ; registered grandfathered codes that are well-formed, but would not otherwise be valid
irregulari = "ami" / "bnn" / "default" / "enochian" / "hak" / "klingon" / "lux" / "mingo" / "navajo" / "pwn" / "tao" / "tay" / "tsu"
irregularEverson = "en-GB-oed" / "sgn-BE-fr" / "sgn-BE-nl" / "sgn-CH-de"

Mark

On 9/17/06, Addison Phillips <addison@yahoo-inc.com> wrote:
Good point. I like the idea of the irregular list.

Addison

John Cowan wrote:
> Section 2.2.9 of RFC 4646 says:
>
>    An implementation that claims to check for well-formed language tags
>    MUST:
>
>    o  Check that the tag and all of its subtags, including extension and
>       private use subtags, conform to the ABNF OR that the tag is on the
>       list of grandfathered tags.
>
>    o  Check that singleton subtags that identify extensions do not
>       repeat.  For example, the tag "en-a-xx-b-yy-a-zz" is not well-
>       formed.
>
> (I have emphasized the word OR in the first bullet point.)
>
> Unfortunately, this wording allows too much.  For example, the invalid tag
> "ra-bb-it" matches the "grandfathered" rule in the ABNF.  Therefore it
> winds up being well-formed even though it cannot be analyzed as a sequence
> of subtags and is not on the grandfathered list either.
>
> To avoid this, we can take one of two actions:
>
> 1) Remove the "grandfathered" production in the ABNF altogether, and use
> the "OR" in the conformance clause to allow the irregular grandfathered
> tags (that is, those which don't match the "langtag" or "privateuse"
> productions) to be well-formed.  The danger here is that people will
> implement the ABNF only, and the grandfathered tags will become outright
> unusable rather than merely discouraged.
>
> 2) Add an explicit "irregular" production in place of the "grandfathered"
> production which explicitly enumerates the 17 irregular grandfathered
> tags, thus:
>
> 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"
>
> It is safe to enumerate this list explicitly, as it can neither grow
> nor shrink.  It's true that all the tags except "i-default" can become
> deprecated, but that makes no difference to well-formed processors.
> The other grandfathered tags in the registry are all well-formed already
> and do not need to be in this list.
>
> In this case the conformance clause can be simplified by omitting the
> second part of the "OR".
>
> I favor choice 2.
>

--
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

------=_Part_166130_8520362.1158530938593-- --===============0456100698== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0456100698==-- From ltru-bounces@ietf.org Sun Sep 17 18:24:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP53j-0007gs-MC; Sun, 17 Sep 2006 18:24:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP53i-0007gn-4r for ltru@ietf.org; Sun, 17 Sep 2006 18:24:18 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP53g-0004em-RR for ltru@ietf.org; Sun, 17 Sep 2006 18:24:18 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GP53g-0005yE-EL for ltru@ietf.org; Sun, 17 Sep 2006 18:24:16 -0400 Date: Sun, 17 Sep 2006 18:24:16 -0400 To: ltru@ietf.org Message-ID: <20060917222416.GA3003@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [Ltru] On deprecating 639-2 language collections X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org With the introduction of language subtags for most of the known languages of the world, it's time to consider deprecating ISO 639-2-derived subtags that represent collections of languages (as distinct from macrolanguages). Under RFC 4646, if you want to tag a text in a Native American language from North America that does not have its own subtag, the best you can do is use the collection subtag "nai". Now, however, all those languages will appear under their own names with their own subtags, and "nai" will never be necessary and rarely useful. In addition, many of the collection subtags are for genetic groups, like 'dra' "Dravidian languages (Other)" and so are essentially unstable, because the list of which languages are considered Dravidian may change over time. Therefore, I decided to investigate how much, and which, language collection subtags would be deprecated. There are 68 code elements that appear in 639-2 but not 693-3, excluding the bibliographic codes like 'ger', 'alb', and so on that are not used in either 639-3 or RFC 4646. One of these, 'sgn', is a special case, to be treated by 4646bis as a de facto macrolanguage. Of the remaining 67, 55 are uncontroversially collections; they include either the string "languages" (as in 'nai', "North American languages") or the string "(Other)" (as in 'dra', "Dravidian (Other)") in their 639-2 names. (Note that 'mul', "Multiple languages", contains the string "languages" in its name but is part of 639-3 and should not be deprecated; 'sgn' likewise should not be deprecated.) The remaining 12 codes appear below. The 14th Edition of the Ethnologue is now obsolete, but still useful for explicating the Ethnologue view (and implicitly the 639-3 view) of these codes: see http://www.ethnologue.com/14/show_iso639.asp?code=xxx for information on 639-2 code xxx. 'bad', "Banda" 'bih', "Bihari" 'btk', "Batak (Indonesia)" 'day', "Dayak" 'him', "Himachali" 'ijo', "Ijo" 'kar', "Karen" 'kro', "Kru" 'nah', "Nahuatl" 'nqo', "N'ko" 'son', "Songhai" 'znd', "Zande" Notes: There is a 639-3 language called 'bnd', "Banda", which is a particular member of the 'bad' collection; and analogously for 'zne', "Zande (specific)". The 14th edition says this about 'day': The term "Dayak" is particularly problematic. It is a cover term used to refer to all non-Muslim peoples of Borneo. It is not a linguistic identifier, nor does it even refer to a single ethnic identity. According to MARC information, this code has been used in reference to various languages from several distinct branches of Western-Malayo-Polonesian, and thus it also does not correspond to some node in a genetic classification. 'nqo' does not appear in the 14th edition at all. It is to be hoped that these 12 discrepancies are cleaned up in some way by the 639/RA-JAC before RFC 4646bis goes into effect. In any case, my proposal is that all the code elements of 639-2 that are not in 639-3, with the sole exception of 'sgn', should be deprecated as of Date C with a comment of "Collection of languages" or the like. -- By Elbereth and Luthien the Fair, you shall cowan@ccil.org have neither the Ring nor me! --Frodo http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 18:42:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP5LE-0004Y0-67; Sun, 17 Sep 2006 18:42:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP5LD-0004W7-8I for ltru@ietf.org; Sun, 17 Sep 2006 18:42:23 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP5LC-00016J-13 for ltru@ietf.org; Sun, 17 Sep 2006 18:42:23 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GP5LB-0007Im-PN; Sun, 17 Sep 2006 18:42:21 -0400 Date: Sun, 17 Sep 2006 18:42:21 -0400 To: Mark Davis Subject: Re: [Ltru] RFC 4646 production "grandfathered" considered harmful Message-ID: <20060917224221.GB3003@ccil.org> References: <20060917061912.GB26073@ccil.org> <450D81D7.1070004@yahoo-inc.com> <30b660a20609171508s36585ea5r2311f0ac4c3cb2fe@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20609171508s36585ea5r2311f0ac4c3cb2fe@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > I do as well. Note that the BNF provides both checks of well-formedness > (partial, because of repeating extensions), but also a division into > semantic units. Well, it does and it doesn't. It's true that "grandfathered" matches all the grandfathered tags (and much else as well); but "langtag" matches a good many grandfathered tags. So I'd like to make a firm distinction between syntactic irregularity (tags which cannot be decomposed into subtags) and semantic grandfathering (tags which, if they can be decomposed, produce the wrong meaning). > irregulari = "ami" / "bnn" / "default" / "enochian" / "hak" / "klingon" / > "lux" / "mingo" / "navajo" / "pwn" / "tao" / "tay" / "tsu" This would save a little vertical space, but not much else. -- "The serene chaos that is Courage, and the phenomenon cowan@ccil.org of Unopened Consciousness have been known to the John Cowan Great World eons longer than Extaboulism." "Why is that?" the woman inquired. "Because I just made that word up", the Master said wisely. --Kehlog Albran, The Profit http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 18:59:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP5bS-0000wb-Hd; Sun, 17 Sep 2006 18:59:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP5bR-0000wU-Bp for ltru@ietf.org; Sun, 17 Sep 2006 18:59:09 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP5bN-00056E-Vd for ltru@ietf.org; Sun, 17 Sep 2006 18:59:09 -0400 Received: from [10.72.76.233] (snvvpn2-10-72-76-c233.corp.yahoo.com [10.72.76.233]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8HMwsFn003362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Sep 2006 15:58:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=JmvR7cgK3Z1vxn4QEVC/+zHtR8hQNotqfpZFp2uxNRuLMu25N3DjbJWujVvUj+pq Message-ID: <450DD32E.5060604@yahoo-inc.com> Date: Sun, 17 Sep 2006 15:58:54 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Re: UTF-8 References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> <6.0.0.20.2.20060916114849.081056e0@localhost> <450BD347.9EA@xyzzy.claranet.de> <6.0.0.20.2.20060917154808.08a12880@localhost> <20060917183821.GC26073@ccil.org> <450DA2D1.6020706@yahoo-inc.com> <20060917210513.GF26073@ccil.org> In-Reply-To: <20060917210513.GF26073@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > >> But that consideration doesn't apply to the registry file. It only >> applies to the discussion of a registry entry on ietf-languages. >> Admittedly MUAs vary greatly in their support for encodings, but we can >> certainly specify directions for how to send the registration request to >> the list so that everyone can tell what code points are intended and >> other instructions for how to encode those characters in the registry. > > Directions which work uniformly across all native encodings, operating > environments, and mailers? I venture to doubt it. > Uh... how about something like "in your registration form, non-ASCII code points must be encoded as an XML-like NCR" I didn't say that the registration forms had to support non-ASCII. Only that it be possible for everyone to tell what the code points were supposed to be and for IANA to arrive at a UTF-8 registry from them. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 19:09:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP5lL-0003fU-NE; Sun, 17 Sep 2006 19:09:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP5lK-0003fO-Qs for ltru@ietf.org; Sun, 17 Sep 2006 19:09:22 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP5lJ-0006iN-Ct for ltru@ietf.org; Sun, 17 Sep 2006 19:09:22 -0400 Received: from [10.72.76.233] (snvvpn2-10-72-76-c233.corp.yahoo.com [10.72.76.233]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8HN9Chx003748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Sep 2006 16:09:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=tTECK3ZztSXb2SZM/8SVnr7E8LpAfiZivIDC0IGkBVg9IUU+RAZPAjbfygTNHjuO Message-ID: <450DD598.9080404@yahoo-inc.com> Date: Sun, 17 Sep 2006 16:09:12 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] On deprecating 639-2 language collections References: <20060917222416.GA3003@ccil.org> In-Reply-To: <20060917222416.GA3003@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I'd prefer to tinker with the code lists as little as possible. I think that, with the introduction of 4646bis and 639-3, it might be wise to add some text in Section 4.1 (Choice) along the lines of: --- #. Use specific language subtags or subtag sequences in preference to subtags for language collections. A "language collection" is a subtag derived from one of the ISO 639-2 codes that represents multiple related languages. For example, the code 'nai' represents "North American languages". The registry contains values for the specific languages represented by this collective code. For example 'xxx' (language1) and 'yyy' (language2). Note that these languages are otherwise unrelated. --- I wouldn't have a problem with deprecating these codes. Should we provide a list of Prefix values? Addison John Cowan wrote: > With the introduction of language subtags for most of the known languages > of the world, it's time to consider deprecating ISO 639-2-derived subtags > that represent collections of languages (as distinct from macrolanguages). > > Under RFC 4646, if you want to tag a text in a Native American language > from North America that does not have its own subtag, the best you > can do is use the collection subtag "nai". Now, however, all those > languages will appear under their own names with their own subtags, and > "nai" will never be necessary and rarely useful. In addition, many of > the collection subtags are for genetic groups, like 'dra' "Dravidian > languages (Other)" and so are essentially unstable, because the list of > which languages are considered Dravidian may change over time. > > Therefore, I decided to investigate how much, and which, language > collection subtags would be deprecated. > > There are 68 code elements that appear in 639-2 but not 693-3, excluding > the bibliographic codes like 'ger', 'alb', and so on that are not used > in either 639-3 or RFC 4646. One of these, 'sgn', is a special case, > to be treated by 4646bis as a de facto macrolanguage. > > Of the remaining 67, 55 are uncontroversially collections; they include > either the string "languages" (as in 'nai', "North American languages") > or the string "(Other)" (as in 'dra', "Dravidian (Other)") in their > 639-2 names. (Note that 'mul', "Multiple languages", contains the string > "languages" in its name but is part of 639-3 and should not be deprecated; > 'sgn' likewise should not be deprecated.) > > The remaining 12 codes appear below. The 14th Edition of the > Ethnologue is now obsolete, but still useful for explicating the > Ethnologue view (and implicitly the 639-3 view) of these codes: see > http://www.ethnologue.com/14/show_iso639.asp?code=xxx for information > on 639-2 code xxx. > > 'bad', "Banda" > 'bih', "Bihari" > 'btk', "Batak (Indonesia)" > 'day', "Dayak" > 'him', "Himachali" > 'ijo', "Ijo" > 'kar', "Karen" > 'kro', "Kru" > 'nah', "Nahuatl" > 'nqo', "N'ko" > 'son', "Songhai" > 'znd', "Zande" > > Notes: > > There is a 639-3 language called 'bnd', "Banda", which is a particular > member of the 'bad' collection; and analogously for 'zne', "Zande > (specific)". > > The 14th edition says this about 'day': > > The term "Dayak" is particularly problematic. It is a cover term > used to refer to all non-Muslim peoples of Borneo. It is not a > linguistic identifier, nor does it even refer to a single ethnic > identity. According to MARC information, this code has been > used in reference to various languages from several distinct > branches of Western-Malayo-Polonesian, and thus it also does > not correspond to some node in a genetic classification. > > 'nqo' does not appear in the 14th edition at all. > > It is to be hoped that these 12 discrepancies are cleaned up in some way > by the 639/RA-JAC before RFC 4646bis goes into effect. In any case, my > proposal is that all the code elements of 639-2 that are not in 639-3, > with the sole exception of 'sgn', should be deprecated as of Date C with > a comment of "Collection of languages" or the like. > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 19:10:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP5mp-00046o-Im; Sun, 17 Sep 2006 19:10:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP5mp-00046j-BI for ltru@ietf.org; Sun, 17 Sep 2006 19:10:55 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP5mm-0007Rd-Kf for ltru@ietf.org; Sun, 17 Sep 2006 19:10:54 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GP5mm-0000aM-AK; Sun, 17 Sep 2006 19:10:52 -0400 Date: Sun, 17 Sep 2006 19:10:50 -0400 To: Addison Phillips Subject: Re: [Ltru] Re: UTF-8 Message-ID: <20060917231050.GC3003@ccil.org> References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> <6.0.0.20.2.20060916114849.081056e0@localhost> <450BD347.9EA@xyzzy.claranet.de> <6.0.0.20.2.20060917154808.08a12880@localhost> <20060917183821.GC26073@ccil.org> <450DA2D1.6020706@yahoo-inc.com> <20060917210513.GF26073@ccil.org> <450DD32E.5060604@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450DD32E.5060604@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Uh... how about something like "in your registration form, non-ASCII > code points must be encoded as an XML-like NCR" > > I didn't say that the registration forms had to support non-ASCII. Only > that it be possible for everyone to tell what the code points were > supposed to be and for IANA to arrive at a UTF-8 registry from them. Okay, I'm fine with that, provided the NCR version remains as the normative version of the registry; this is justified by *stare decisis*. -- John Cowan http://ccil.org/~cowan cowan@ccil.org There are books that are at once excellent and boring. Those that at once leap to the mind are Thoreau's Walden, Emerson's Essays, George Eliot's Adam Bede, and Landor's Dialogues. --Somerset Maugham _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 19:30:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP65k-0001Pv-BA; Sun, 17 Sep 2006 19:30:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP65i-0001KI-Ii for ltru@ietf.org; Sun, 17 Sep 2006 19:30:26 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP65e-0003kw-8m for ltru@ietf.org; Sun, 17 Sep 2006 19:30:26 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060917233021.FNOT27224.mta10.adelphia.net@DGBP7M81> for ; Sun, 17 Sep 2006 19:30:21 -0400 Message-ID: <018701c6dab1$3ef889e0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 17 Sep 2006 16:30:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.6 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Ltru] Re: Process for creating 4646bis Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> The new inputs to the Registry are the ISO/FDIS 639-3 online code >> tables. > > For the drafts before Last Call. For the registry it should be the > then existing ISO 639-3:2007. Of course. >> the subtag "gd" currently has the descriptions "Gaelic" and "Scottish >> Gaelic"; the new description "Gaelic (Scots)" from 639-3 will be >> added. > > As Randy and Debbie wanted it. You had convinced me that replacing > xxxx by xxxx (yyyy) instead of adding it might be okay, but for a > first draft any consistent rule goes, we know that it's an open issue. I had assumed that keeping all the old Descriptions was the hum of the group. We don't seem to be using the issue tracking tool this time, and I haven't seen the co-chairs declare consensus on anything yet. I'm trying to gauge consensus myself, and we know how dangerous it can be when individual members start doing that. >> No existing Description fields are changed or deleted. > > ACK, that's KISS, please note it explicitly. I just did. :-) [extlangs] > It's another open issue, compare > http://permalink.gmane.org/gmane.ietf.ltru/5420 > For the first draft it's fine, let's look at the output, and then > decide if we really like this "macrolanguage" cruft. The job of > 4646bis is to define language tags, not to sanction the POVs of its > sources, for that folks should read these sources, not the registry. Again, there is no ticket and no consensus or hum declared by the co-chairs. We'd better decide this pivotal question soon. I have 13 days left to submit a first draft and I will be out of town for four of them. >> zh-hakka -> zh-hak > > Resulting in i-hak -> zh-hakka -> zh-hak (JFTR, we have to eat our dog > food) Correct. The Registry points "i-hak" to "zh-hakka" and points "zh-hakka" to "zh-hak", and validating processors that automatically "correct" deprecated tags and subtags to their preferred brethren will need to correct "i-hak" directly to "zh-hak". >> zh-min -> (no Preferred-Value, just deprecated) > > That has to be justified explicitly in prose, as an exception. Does it? The Preferred-Values for the others are explicitly listed to show how the tags were mapped. The judgment of the WG is involved, although I think in these cases it will be unassailable. In the case of "zh-min" the judgment of the WG is that (a) the tag is deprecated because it doesn't refer to a real language and (b) there is no Preferred-Value because no alternative tagging possibility exists for this non-language. >> http://users.adelphia.net/~dewell/lstreg-4646bis.txt > > Thanks, quick check with the W3C validator (8167 records): One known > yi-latn (lower case L) error, anything else okay. It's not an error, as I said before. Case is not significant in RFC { 1766, 3066, 4646, 4646bis } language tags. There happen to be conventions for casing, and the Registry uses those conventions, but they are not normative. IMHO it would be more of an error if we "corrected" the case of a previously registered tag; the whole point of keeping redundant tags in the Registry is to preserve them in a museum-like setting. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 19:33:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP68n-0002QH-EL; Sun, 17 Sep 2006 19:33:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP68m-0002QC-NN for ltru@ietf.org; Sun, 17 Sep 2006 19:33:36 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP68l-0004Tv-G9 for ltru@ietf.org; Sun, 17 Sep 2006 19:33:36 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GP68k-0001xy-Ti; Sun, 17 Sep 2006 19:33:34 -0400 Date: Sun, 17 Sep 2006 19:33:34 -0400 To: Addison Phillips Subject: Re: [Ltru] On deprecating 639-2 language collections Message-ID: <20060917233334.GE3003@ccil.org> References: <20060917222416.GA3003@ccil.org> <450DD598.9080404@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450DD598.9080404@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > #. Use specific language subtags or subtag sequences in preference to > subtags for language collections. A "language collection" is a subtag > derived from one of the ISO 639-2 codes that represents multiple related > languages. For example, the code 'nai' represents "North American > languages". The registry contains values for the specific languages > represented by this collective code. For example 'xxx' (language1) and > 'yyy' (language2). All well and good, except that it provides no definite guidance on which language subtags are for collections. Deprecating them does. > Note that these languages are otherwise unrelated. Not always true. Indeed, I would say that the bulk of the 639-2 collection code elements do in fact represent either genetic subgroups or genetic subgroups with some languages or sub-subgroups removed. > I wouldn't have a problem with deprecating these codes. All right then. :-) > Should we provide a list of Prefix values? I don't understand. Do you mean a list of Preferred-Value values? I'd say no; the collective subtag 'map', "Austronesian (Other)", encompasses 1038 languages in Ethnologue-14, and the list may well have grown since then. Furthermore, it is highly subject to change as additional Austronesian languages are added or even removed due to advances in knowledge. -- If you have ever wondered if you are in hell, John Cowan it has been said, then you are on a well-traveled http://www.ccil.org/~cowan road of spiritual inquiry. If you are absolutely cowan@ccil.org sure you are in hell, however, then you must be on the Cross Bronx Expressway. --Alan Feuer, NYTimes, 2002-09-20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 19:33:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP696-0002Vs-N2; Sun, 17 Sep 2006 19:33:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP695-0002Vm-E4 for ltru@ietf.org; Sun, 17 Sep 2006 19:33:55 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP693-0004Y6-5u for ltru@ietf.org; Sun, 17 Sep 2006 19:33:55 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060917233352.FRHZ27224.mta10.adelphia.net@DGBP7M81> for ; Sun, 17 Sep 2006 19:33:52 -0400 Message-ID: <018d01c6dab1$bcc3c150$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 17 Sep 2006 16:33:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > Regex: ((?: [a-z A-Z]{2,3} (?: [-] [a-z A-Z]{3} ){0,3} | [a-z > A-Z]{4,8} > ))(?: [-] ((?: [a-z A-Z]{4} )) )?(?: [-] ((?: [a-z A-Z]{2} | > [0-9]{3} )) > )?(?: [-] ((?: (?: [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) (?: > [-] (?: > [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) )* )) )?(?: [-] ((?: (?: > [a-w > y-z A-W Y-Z] (?: [-] [a-z A-Z 0-9]{2,8} )+ ) (?: [-] (?: [a-w y-z A-W > Y-Z] > (?: [-] [a-z A-Z 0-9]{2,8} )+ ) )* )) )?(?: [-] ((?: [xX] (?: [-] [a-z > A-Z > 0-9]{1,8} )+ )) )?| ( (?i) art [-] lojban| cel [-] gaulish| en [-] (?: > boont > | GB [-] oed | scouse )| i [-] (?: ami | bnn | default | enochian | > hak | > klingon | lux | mingo | navajo | pwn | tao | tay | tsu )| no [-] (?: > bok | > nyn)| sgn [-] (?: BE [-] fr | BE [-] nl | CH [-] de)| zh [-] (?: cmn | > zh > [-] cmn [-] Hans | cmn [-] Hant | gan | guoyu | hakka | min | min [-] > nan | > wuu | xiang | yue))| ((?: [xX] (?: [-] [a-z A-Z 0-9]{1,8} )+ )) Good Lord. I don't know if you should be proud or ashamed of that. Probably both. See also: http://en.wikipedia.org/wiki/Obfuscated_code -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 19:36:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP6Bs-0003CO-Cq; Sun, 17 Sep 2006 19:36:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP6Br-0003CJ-1S for ltru@ietf.org; Sun, 17 Sep 2006 19:36:47 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP6Bp-0005eV-RD for ltru@ietf.org; Sun, 17 Sep 2006 19:36:47 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GP6Bp-00022z-KC; Sun, 17 Sep 2006 19:36:45 -0400 Date: Sun, 17 Sep 2006 19:36:45 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Process for creating 4646bis Registry Message-ID: <20060917233645.GF3003@ccil.org> References: <018701c6dab1$3ef889e0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <018701c6dab1$3ef889e0$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > Does it? The Preferred-Values for the others are explicitly listed to > show how the tags were mapped. The judgment of the WG is involved, > although I think in these cases it will be unassailable. In the case of > "zh-min" the judgment of the WG is that (a) the tag is deprecated > because it doesn't refer to a real language and (b) there is no > Preferred-Value because no alternative tagging possibility exists for > this non-language. It's a language collection in any case, encompassing 'mnp', 'cdo', 'nan', and 'czo', and therefore should be deprecated for the same reasons as the 639-2 collection subtags. -- Normally I can handle panic attacks on my own; John Cowan but panic is, at the moment, a way of life. http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 19:43:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP6I3-0004ww-Gs; Sun, 17 Sep 2006 19:43:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP6I1-0004wd-Ur for ltru@ietf.org; Sun, 17 Sep 2006 19:43:09 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP6I0-0008HM-NJ for ltru@ietf.org; Sun, 17 Sep 2006 19:43:09 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060917234308.GCZB27224.mta10.adelphia.net@DGBP7M81> for ; Sun, 17 Sep 2006 19:43:08 -0400 Message-ID: <019301c6dab3$07e30f00$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 17 Sep 2006 16:43:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > By the way: nothing says we have to put the actual updated registry > into the I-D. Yes, we did it that way last time. But that is NOT the > only way to transmit data to them. And I purposely selected the text > in 4646bis-00 to *not* specifically state what form the update would > take. In that case, there would be no point in having a 4645bis, since the rules for bulk-revising the Registry could be incorporated directly into 4646bis. I'm not saying that's a bad thing. > I would suggest that it would be just as easy and/or better to specify > that the LSTR (via his technical helper, aka Doug) create and verify > the updated registry before forwarding it. I completely defer to the "pros" who have lengthy experience working with IETF and IANA on things like this. > In fact, I've been thinking about text that Doug could use in 4645bis > to manage the interregnum process and I'll send that to the list > shortly. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 19:57:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP6W9-0000vR-03; Sun, 17 Sep 2006 19:57:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP6W8-0000v6-3k for ltru@ietf.org; Sun, 17 Sep 2006 19:57:44 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP6W6-0004bq-MT for ltru@ietf.org; Sun, 17 Sep 2006 19:57:44 -0400 Received: by nf-out-0910.google.com with SMTP id n15so2925459nfc for ; Sun, 17 Sep 2006 16:57:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=DM3E6YLcGjSiqxPH68j9At9nTkdD72rc+YhKJH8HC2nzUELthLrAlE20EwPiPtkPMk38VftVzOX/lI/e6UHcwUxWsNFj5exCcrJgefQuzqd1Cbwhus/EAaNjGYX3HGkrHa/7qQDF6vm3CShLV7a2suw+xZL92DM40u77geYFnI8= Received: by 10.49.29.3 with SMTP id g3mr16305101nfj; Sun, 17 Sep 2006 16:57:41 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Sun, 17 Sep 2006 16:57:41 -0700 (PDT) Message-ID: <30b660a20609171657g7c6e1febs26fd68de0c1ad83b@mail.gmail.com> Date: Sun, 17 Sep 2006 17:57:41 -0600 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Test suite for language tags? In-Reply-To: <018d01c6dab1$bcc3c150$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <018d01c6dab1$bcc3c150$6401a8c0@DGBP7M81> X-Google-Sender-Auth: 9f24711648b1c76a X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1037286896==" Errors-To: ltru-bounces@ietf.org --===============1037286896== Content-Type: multipart/alternative; boundary="----=_Part_167128_12674809.1158537461114" ------=_Part_167128_12674809.1158537461114 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline LOL. I don't think you saw the earlier message; this is machine-generated. Mark On 9/17/06, Doug Ewell wrote: > > Mark Davis wrote: > > > Regex: ((?: [a-z A-Z]{2,3} (?: [-] [a-z A-Z]{3} ){0,3} | [a-z > > A-Z]{4,8} > > ))(?: [-] ((?: [a-z A-Z]{4} )) )?(?: [-] ((?: [a-z A-Z]{2} | > > [0-9]{3} )) > > )?(?: [-] ((?: (?: [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) (?: > > [-] (?: > > [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) )* )) )?(?: [-] ((?: (?: > > [a-w > > y-z A-W Y-Z] (?: [-] [a-z A-Z 0-9]{2,8} )+ ) (?: [-] (?: [a-w y-z A-W > > Y-Z] > > (?: [-] [a-z A-Z 0-9]{2,8} )+ ) )* )) )?(?: [-] ((?: [xX] (?: [-] [a-z > > A-Z > > 0-9]{1,8} )+ )) )?| ( (?i) art [-] lojban| cel [-] gaulish| en [-] (?: > > boont > > | GB [-] oed | scouse )| i [-] (?: ami | bnn | default | enochian | > > hak | > > klingon | lux | mingo | navajo | pwn | tao | tay | tsu )| no [-] (?: > > bok | > > nyn)| sgn [-] (?: BE [-] fr | BE [-] nl | CH [-] de)| zh [-] (?: cmn | > > zh > > [-] cmn [-] Hans | cmn [-] Hant | gan | guoyu | hakka | min | min [-] > > nan | > > wuu | xiang | yue))| ((?: [xX] (?: [-] [a-z A-Z 0-9]{1,8} )+ )) > > Good Lord. I don't know if you should be proud or ashamed of that. > Probably both. > > See also: > http://en.wikipedia.org/wiki/Obfuscated_code > > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > RFC 4645 * UTN #14 > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_167128_12674809.1158537461114 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline LOL. I don't think you saw the earlier message; this is machine-generated.

Mark

On 9/17/06, Doug Ewell <dewell@adelphia.net > wrote:
Mark Davis <mark dot davis at icu dash project dot org> wrote:

> Regex: ((?: [a-z A-Z]{2,3} (?: [-] [a-z A-Z]{3} ){0,3} | [a-z
> A-Z]{4,8}
> ))(?: [-] ((?: [a-z A-Z]{4} )) )?(?: [-] ((?: [a-z A-Z]{2} |
> [0-9]{3} ))
> )?(?: [-] ((?: (?: [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) (?:
> [-] (?:
> [0-9] [a-z A-Z 0-9]{3} | [a-z A-Z 0-9]{5,8} ) )* )) )?(?: [-] ((?: (?:
> [a-w
> y-z A-W Y-Z] (?: [-] [a-z A-Z 0-9]{2,8} )+ ) (?: [-] (?: [a-w y-z A-W
> Y-Z]
> (?: [-] [a-z A-Z 0-9]{2,8} )+ ) )* )) )?(?: [-] ((?: [xX] (?: [-] [a-z
> A-Z
> 0-9]{1,8} )+ )) )?| ( (?i) art [-] lojban| cel [-] gaulish| en [-] (?:
> boont
> | GB [-] oed | scouse )| i [-] (?: ami | bnn | default | enochian |
> hak |
> klingon | lux | mingo | navajo | pwn | tao | tay | tsu )| no [-] (?:
> bok |
> nyn)| sgn [-] (?: BE [-] fr | BE [-] nl | CH [-] de)| zh [-] (?: cmn |
> zh
> [-] cmn [-] Hans | cmn [-] Hant | gan | guoyu | hakka | min | min [-]
> nan |
> wuu | xiang | yue))| ((?: [xX] (?: [-] [a-z A-Z 0-9]{1,8} )+ ))

Good Lord.  I don't know if you should be proud or ashamed of that.
Probably both.

See also:
http://en.wikipedia.org/wiki/Obfuscated_code

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
RFC 4645  *  UTN #14


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

------=_Part_167128_12674809.1158537461114-- --===============1037286896== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1037286896==-- From ltru-bounces@ietf.org Sun Sep 17 21:12:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP7gH-0005NK-HK; Sun, 17 Sep 2006 21:12:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP7gG-0005My-H3 for ltru@lists.ietf.org; Sun, 17 Sep 2006 21:12:16 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP7gB-0008PV-7R for ltru@lists.ietf.org; Sun, 17 Sep 2006 21:12:16 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GP7g8-0002db-GA for ltru@lists.ietf.org; Mon, 18 Sep 2006 03:12:08 +0200 Received: from du-042-227.access.de.clara.net ([213.221.65.227]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 03:12:08 +0200 Received: from nobody by du-042-227.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 03:12:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Sep 2006 03:05:26 +0200 Organization: Lines: 17 Message-ID: <450DF0D6.1BEA@xyzzy.claranet.de> References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> <6.0.0.20.2.20060916114849.081056e0@localhost> <450BD347.9EA@xyzzy.claranet.de> <6.0.0.20.2.20060917154808.08a12880@localhost> <20060917183821.GC26073@ccil.org> <450DA2D1.6020706@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-042-227.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I find this fascination with ASCII slightly quaint. I vaguely recall a day when I read a beginner's book about PASCAL, and was annoyed by its ASCII table, because it had nothing to do with "real world standards" (at that time a "real world standard" had a IBM GA number and used EBDCIC ;-) Charsets in general are fascinating. Admittedly I'm less thrilled by SCSU (implementing it takes more than 5 minutes, so far I got it). Frank -- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 21:26:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP7uH-0001Sv-5y; Sun, 17 Sep 2006 21:26:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP7uG-0001Sq-6C for ltru@ietf.org; Sun, 17 Sep 2006 21:26:44 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP7uE-0004J2-7E for ltru@ietf.org; Sun, 17 Sep 2006 21:26:44 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8I1QejE024822 for ; Mon, 18 Sep 2006 10:26:40 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 3744_bc51b50a_46b4_11db_849f_0014221fa3c9; Mon, 18 Sep 2006 10:26:40 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49525) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 18 Sep 2006 10:26:45 +0900 Message-Id: <6.0.0.20.2.20060917161407.088b7ce0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 17 Sep 2006 16:29:34 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Process for creating 4646bis Registry In-Reply-To: <010201c6da1a$3405ad70$6401a8c0@DGBP7M81> References: <010201c6da1a$3405ad70$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Doug, Many thanks for your work. As a co-chair, I strongly suggest that you submit your text below and your data as an Internet-Draft as soon as possible. This is NOT because I want us to meet the deadline in September, but because this is the way work is done in the IETF. Also, I'd like to see how well the Internet-Drafts system takes this (almost) mega-draft. As a filename, my suggestion is draft-ietf-ltru-4645bis-00.txt, but any other suggestion is welcome. The main problem with the above name is that it may be too close to draft-ietf-ltru-4646bis-00.txt. Some comments as a technical contributor below. At 14:29 06/09/17, Doug Ewell wrote: >Here is my first pass at describing the process for generating the RFC 4646bis Language Subtag Registry. This is not necessarily the exact wording that will appear in RFC 4645bis, but parts of it may end up there with little or no change. > >This needs to be evaluated by the WG on at least two levels: > >* the process itself >* the way the process is described (logic, clarity, ambiguity, mechanics, etc.) > >1. Starting point > >The existing Registry serves as the starting point for the new Registry. RFC 4645bis will include a reference (probably normative) No, this should be informative, because there is no need to go back to RFC 4645 unless for informational purposes. >to RFC 4645 for those who wish to trace the path all the way back to the ISO and UN standards and RFC 3066 tag registry. > >The new inputs to the Registry are the ISO/FDIS 639-3 online code tables. This includes the code set dated 2006-04-21 and the macrolanguage mappings dated 2005-06-14, which are currently (2006-09-16) available on the ISO 639-3 home page. Peter has said there are changes in the FDIS document not reflected in these files, and more changes will be coming, but I am using these files because they are the most up-to-date information available to me. Great. >2. Language subtags modified > >The existing Registry includes 489 primary language subtags, including some for "language collections" not included in 639-3. In cases where the reference name(s) in 639-3 for these languages differ(s) from the Description fields in the Registry, the new names are added to the existing Registry entry, after all existing descriptions. For example, the subtag "gd" currently has the descriptions "Gaelic" and "Scottish Gaelic"; the new description "Gaelic (Scots)" from 639-3 will be added. This includes inverted forms of existing names, such as "Frisian, Northern". > >This also includes language names that include a country name, to differentiate them from other languages of the same name associated with a different country. For example, the subtag "bas" currently has the description "Basa"; to this would be added "Basa (Cameroon)" from 639-3. The new subtag "bzw" would have the single description "Basa (Nigeria)". > >Reference names in the 639-3 files that contain the strings "(generic)" or "(specific)" are changed to "(macrolanguage)" and the empty string, respectively, in accordance with Peter's statement on September 12 that the FDIS already includes this change. The single exception is "Zande (specific)" (zne), which is left unchanged because there is also a 639-3 code element "Zande" (znd) and neither of these is a macrolanguage. Can we expect this to be fixed (i.e. the two Zande to be disambiguated) in a newer version of 639-3? Peter? >No existing Description fields are changed or deleted. > >3. New subtags added > >All 639-3 code elements not in the LSR are added as primary language subtags if they are not included under a 639-3 macrolanguage, or as extended language subtags if they are (with the macrolanguage as Prefix). This is consistent with John Cowan's description of the process, which was generally approved by the list. > >As a special case, all 639-3 languages with the words "Sign Language" in their name are added as extlangs, with "sgn" as the Prefix. This is the same as if 639-3 had listed them under a macrolanguage "sgn". (The entry "sgn", being a collection code, is not present in 639-3 at all.) > >All subtags added to the Registry are added in alphabetical order within their type, with the 2-letter language subtags appearing before the 3-letter subtags. IANA previously added two 3-letter subtags, "anp" and "frr", in the section for 2-letter subtags, which is allowed by RFC 4646 but may surprise some readers. No attempt is made here to change this. I think that if we want things in a certain order, we should put them into that order, and say so in 4646bis. >4. Grandfathered and redundant tags > >As a consequence of adding these new subtags, the following grandfathered tags are deprecated, with the indicated tag specified as Preferred-Value: > >i-ami -> ami >i-bnn -> bnn >i-pwn -> pwn >i-tao -> tao >i-tay -> tay >i-tsu -> tsu >sgn-CH-de -> sgn-sgg >zh-hakka -> zh-hak >zh-min -> (no Preferred-Value, just deprecated) >zh-min-nan -> zh-nan >zh-xiang -> zh-hns > >Each of these grandfathered tags has a Comment field indicating the ISO 639-3 code element (for example, "replaced by ISO code ami"). This duplicates the Preferred-Value information and is not strictly necessary, but is added for consistency with other grandfathered tags. This comment is also added to the tag "zh-guoyu", which is already deprecated in favor of another grandfathered tag, "zh-cmn" (which will now be redundant; see below). > >The following grandfathered tags are now fully composable and are moved to redundant: > >zh-cmn >zh-cmn-Hans >zh-cmn-Hant >zh-gan >zh-wuu >zh-yue > >The following redundant sign-language tags are deprecated (requiring a change in the RFC 4646 rules, which currently disallow this). > >sgn-BR -> sgn-bzs >sgn-CO > sgn-csn >sgn-DE > sgn-gsg >sgn-DK > sgn-dsl >sgn-ES > sgn-ssp >sgn-FR > sgn-fsl >sgn-GB > sgn-bfi >sgn-GR > sgn-gss >sgn-IE > sgn-isg >sgn-IT > sgn-ise >sgn-JP > sgn-jsl >sgn-MX > sgn-mfs >sgn-NI > sgn-ncs >sgn-NL > sgn-dse >sgn-NO > sgn-nsl >sgn-PT > sgn-psr >sgn-SE > sgn-swl >sgn-US > sgn-ase >sgn-ZA > sgn-sfs > >No change is made to the Description field for these tags, so (for example) "sgn-US" will still have the description "American Sign Language". This is to avoid unintended changes of scope. Great. >5. Availability > >A prototype 4646bis Registry built using these rules, with an arbitrary File-Date (and Added date for all new subtags) of 2007-01-01, is available at: > >http://users.adelphia.net/~dewell/lstreg-4646bis.txt (640,265 bytes) >http://users.adelphia.net/~dewell/lstreg-4646bis.zip (78,943 bytes, PKZip format) > >Please use these files as necessary to evaluate the process. Please do not distribute them or build anything for release based on them; remember that the rules are not final. They will not be changed until a revised version of this process is posted to LTRU, so please download them only once per revision. Thanks again. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 21:26:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP7uJ-0001Ti-9a; Sun, 17 Sep 2006 21:26:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP7uH-0001Sz-KU for ltru@ietf.org; Sun, 17 Sep 2006 21:26:45 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP7uE-0004J5-Uy for ltru@ietf.org; Sun, 17 Sep 2006 21:26:45 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8I1QfOh007629 for ; Mon, 18 Sep 2006 10:26:41 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 365b_bd0b0758_46b4_11db_9068_0014221fa3c9; Mon, 18 Sep 2006 10:26:41 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49525) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 18 Sep 2006 10:26:46 +0900 Message-Id: <6.0.0.20.2.20060917163157.08a0e030@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 17 Sep 2006 16:32:12 +0900 To: John Cowan , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] RFC 4646 production "grandfathered" considered harmful In-Reply-To: <20060917061912.GB26073@ccil.org> References: <20060917061912.GB26073@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Like John, I favor choice 2. Regards, Martin. At 15:19 06/09/17, John Cowan wrote: >Section 2.2.9 of RFC 4646 says: > > An implementation that claims to check for well-formed language tags > MUST: > > o Check that the tag and all of its subtags, including extension and > private use subtags, conform to the ABNF OR that the tag is on the > list of grandfathered tags. > > o Check that singleton subtags that identify extensions do not > repeat. For example, the tag "en-a-xx-b-yy-a-zz" is not well- > formed. > >(I have emphasized the word OR in the first bullet point.) > >Unfortunately, this wording allows too much. For example, the invalid tag >"ra-bb-it" matches the "grandfathered" rule in the ABNF. Therefore it >winds up being well-formed even though it cannot be analyzed as a sequence >of subtags and is not on the grandfathered list either. > >To avoid this, we can take one of two actions: > >1) Remove the "grandfathered" production in the ABNF altogether, and use >the "OR" in the conformance clause to allow the irregular grandfathered >tags (that is, those which don't match the "langtag" or "privateuse" >productions) to be well-formed. The danger here is that people will >implement the ABNF only, and the grandfathered tags will become outright >unusable rather than merely discouraged. > >2) Add an explicit "irregular" production in place of the "grandfathered" >production which explicitly enumerates the 17 irregular grandfathered >tags, thus: > >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" > >It is safe to enumerate this list explicitly, as it can neither grow >nor shrink. It's true that all the tags except "i-default" can become >deprecated, but that makes no difference to well-formed processors. >The other grandfathered tags in the registry are all well-formed already >and do not need to be in this list. > >In this case the conformance clause can be simplified by omitting the >second part of the "OR". > >I favor choice 2. > >-- >John Cowan cowan@ccil.org > "You need a change: try Canada" "You need a change: try China" > --fortune cookies opened by a couple that I know > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 21:26:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP7uJ-0001UH-DX; Sun, 17 Sep 2006 21:26:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP7uH-0001T4-O6 for ltru@ietf.org; Sun, 17 Sep 2006 21:26:45 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP7uG-0004JH-4A for ltru@ietf.org; Sun, 17 Sep 2006 21:26:45 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8I1Qh3v024828 for ; Mon, 18 Sep 2006 10:26:43 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 369f_bddb1e2a_46b4_11db_80c9_0014221fa3c9; Mon, 18 Sep 2006 10:26:42 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49525) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 18 Sep 2006 10:26:47 +0900 Message-Id: <6.0.0.20.2.20060917163304.08a11c30@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 17 Sep 2006 16:49:56 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] IPA and other transcriptions (was: Re: script tag for IPA) In-Reply-To: <009601c6d9b5$cf9defa0$6401a8c0@DGBP7M81> References: <005701c6d88a$21f245d0$6401a8c0@DGBP7M81> <20060915055401.GC6907@ccil.org> <450A44B6.3060905@sil.org> <6.0.0.20.2.20060915154910.06e040b0@localhost> <450AC979.3050203@yahoo-inc.com> <450B60D4.1040401@sil.org> <004301c6d947$bef6f980$6401a8c0@DGBP7M81> <450C18FA.3090500@sil.org> <009601c6d9b5$cf9defa0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 02:30 06/09/17, Doug Ewell wrote: >Martin Hosken brings up a good case for the existence of text written in, if not 7,000 languages, at least a large percentage of them, using IPA. > >Let me ask a general, related question. We have talked about Wade-Giles and pinyin, and to a much lesser extent McCune-Reischauer and ALA-LC and ISO 9 and other standards and/or conventions for transcribing and/or transliterating languages into a different writing system (not, not "script") for some purpose. > >In what way -- other than the actual repertoire of characters used -- do IPA and other phonetic and phonemic notation systems, differ from those? Well, it's pretty obvious that Wade-Giles is for transcribing Chinese, and only Chinese. Same for pinyin. McCune-Reischauer is for Korean. Single language, as opposed to IPA, which is used widely across languages. ALA-LC is a collection of transcription rules for different languages (in some cases) and scripts (in other cases). There may be some commonalities (my guess would be that one fairly wide commonality is use of consonants close to (some) English pronounciation), but also some differences because these systems are usually based on pre-existing customs (e.g. Japanese following Hepburn, Chinese following pinyin, etc.). So even if syntactically, we could define a variant "alalc", semantically, its meaning would change depending on the language (and script) applied to. ISO 9 is a standard for romanizing Cyrillic, independent of language. All of the examples you mention are very far away from being a script, while IPA is at least close. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 21:26:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP7uM-0001Wh-Hf; Sun, 17 Sep 2006 21:26:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP7uJ-0001Td-7l for ltru@ietf.org; Sun, 17 Sep 2006 21:26:47 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP7uH-0004JO-Jx for ltru@ietf.org; Sun, 17 Sep 2006 21:26:47 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8I1Qiol007635 for ; Mon, 18 Sep 2006 10:26:44 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 3723_beb9b928_46b4_11db_98f4_0014221fa3c9; Mon, 18 Sep 2006 10:26:44 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49525) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 18 Sep 2006 10:26:49 +0900 Message-Id: <6.0.0.20.2.20060917165059.08a0ed10@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 17 Sep 2006 16:57:47 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: UTF-8 In-Reply-To: <005301c6d94a$201174a0$6401a8c0@DGBP7M81> References: <005301c6d94a$201174a0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 13:39 06/09/16, Doug Ewell wrote: >Addison Phillips wrote: >More to the point, changing from record-jar with hex NCR's to *anything* else has to be not just better, but "better enough." The pain and instability caused by the change must be considered, and the benefits must outweigh them. Agreed. In my point of view, the pain of Bokm&#$!@*l outweights a lot of things. The main benefit is that native people can easily check that things are correct, which they won't do if we show them just a number. >> So: >> >> Is there any support for changing to UTF-8? > >I would support it on two conditions: > >1. We must be able to use UTF-8 in the I-D (4645bis) that delivers the Registry contents to IANA. (It's OK if that means the I-D can't be an RFC.) Asking IANA to convert NCR's into UTF-8 themselves would be a disaster. The new Registry will have almost 500 non-ASCII characters. I agree with the fact that we must be able to deliver UTF-8 to IANA. I don't think it necessarily needs to be an I-D. I easily can immagine that you publish an I-D containing just a pointer to an URI and an MD5 for checking. >2. We have to maintain compatibility with the existing format, which means we must continue to escape the ampersand as & if one should ever find its way into the Registry. As I have said in another mail, I'd agree with the continued need for escaping the sequence "&#x", but I don't see any practical relevance for it; we can simply disallow it. For just "&", it may cause a parsing problem for older software the same way UTF-8 may cause a parsing problem, so I don't see the need to keep escaping it. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 21:31:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP7yz-0002hF-Pg; Sun, 17 Sep 2006 21:31:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP7yy-0002h9-Lr for ltru@lists.ietf.org; Sun, 17 Sep 2006 21:31:36 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP7yx-00060O-Bp for ltru@lists.ietf.org; Sun, 17 Sep 2006 21:31:36 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GP7yr-0006M0-Vz for ltru@lists.ietf.org; Mon, 18 Sep 2006 03:31:29 +0200 Received: from du-042-227.access.de.clara.net ([213.221.65.227]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 03:31:29 +0200 Received: from nobody by du-042-227.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 03:31:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Sep 2006 03:24:10 +0200 Organization: Lines: 25 Message-ID: <450DF53A.380@xyzzy.claranet.de> References: <012001c6da7a$a95c46a0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-042-227.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Ltru] Re: RFC 4646 production "grandfathered" considered harmful X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: >>> Add an explicit "irregular" production >> Interesting idea. Maybe add "zh-hakka" as "almost >> irregular", or let's _define_ hakka as deprecated zh >> variant. > "Irregular" means "not conforming to the ABNF of 4646." > I don't see the problem syntactically with "zh-hakka". "Almost irregular" is a registered tag with a reference to an unregistered subtag, and "zh-hakka" is the only tag with this strange "feature" (after 4645bis adds cmn). > There's no problem with "zh-cmn". At the moment (4646) it's another tag with this "feature". You can see why it's a real oddity in the gawk script in All other tags minus yi-latn are straight forward. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 21:36:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP841-0004OB-DB; Sun, 17 Sep 2006 21:36:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP840-0004O6-4H for ltru@ietf.org; Sun, 17 Sep 2006 21:36:48 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP83y-0006xa-Tz for ltru@ietf.org; Sun, 17 Sep 2006 21:36:48 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GP83y-0002Tm-Fu; Sun, 17 Sep 2006 21:36:46 -0400 Date: Sun, 17 Sep 2006 21:36:46 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: RFC 4646 production "grandfathered" considered harmful Message-ID: <20060918013646.GK3003@ccil.org> References: <012001c6da7a$a95c46a0$6401a8c0@DGBP7M81> <450DF53A.380@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450DF53A.380@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > "Almost irregular" is a registered tag with a reference > to an unregistered subtag, and "zh-hakka" is the only tag > with this strange "feature" (after 4645bis adds cmn). How is zh-hakka different from zh-xiang or zh-guoyu (except that the latter is deprecated)? -- John Cowan http://ccil.org/~cowan cowan@ccil.org Lope de Vega: "It wonders me I can speak at all. Some caitiff rogue did rudely yerk me on the knob, wherefrom my wits still wander." An Englishman: "Ay, a filchman to the nab betimes 'll leave a man crank for a spell." --Harry Turtledove, Ruled Britannia _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 21:46:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP8D1-0007S6-8i; Sun, 17 Sep 2006 21:46:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP8D0-0007Ry-Fk for ltru@lists.ietf.org; Sun, 17 Sep 2006 21:46:06 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP8Cz-0008RE-6R for ltru@lists.ietf.org; Sun, 17 Sep 2006 21:46:06 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GP8Ca-0000IR-4p for ltru@lists.ietf.org; Mon, 18 Sep 2006 03:45:40 +0200 Received: from du-042-227.access.de.clara.net ([213.221.65.227]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 03:45:40 +0200 Received: from nobody by du-042-227.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 03:45:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Sep 2006 03:41:37 +0200 Organization: Lines: 24 Message-ID: <450DF951.DE4@xyzzy.claranet.de> References: <011e01c6da79$b7f17330$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-042-227.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Both the current Registry and the prototype 4646bis version > are in NFC. Frankly, it hadn't occurred to me to do it any > other way. The other possibility is to say whatever the sources say. I didn't note that you modified the source descriptions in some way. Please don't do this without a rule for it in 4646bis. > I suppose either 4646bis or 4645bis should state explicitly > that the Registry is in NFC. If that's the case they should most definitely say so. But I don't see the point, just copy what the sources say as long as it's an assigned code-point for a character. > 1 instance of a character not in MES-1 (U+02BB, the "smart" > apostrophe/modifier letter added to Ge'ez). It is in MES-2. Good that we didn't introduce an MES-1 restriction for 4646 :-) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 22:21:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP8lS-00018U-PW; Sun, 17 Sep 2006 22:21:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP8lS-00017a-1j for ltru@lists.ietf.org; Sun, 17 Sep 2006 22:21:42 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP8lQ-0000or-OC for ltru@lists.ietf.org; Sun, 17 Sep 2006 22:21:42 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GP8l0-0008OA-Eq for ltru@lists.ietf.org; Mon, 18 Sep 2006 04:21:15 +0200 Received: from du-042-227.access.de.clara.net ([213.221.65.227]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 04:21:14 +0200 Received: from nobody by du-042-227.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 04:21:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Sep 2006 04:20:02 +0200 Organization: Lines: 20 Message-ID: <450E0252.2840@xyzzy.claranet.de> References: <789E617C880666438EDEE30C2A3E8D10EEFC@mailsrvnt05.enet.sharplabs.com> <450B2B75.2F36@xyzzy.claranet.de> <6.0.0.20.2.20060916114849.081056e0@localhost> <450BD347.9EA@xyzzy.claranet.de> <20060917162451.GA26526@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-042-227.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > This is the sort of things that happen when you reinvent the > wheel, and create a new format for a registry, instead of > trusting existing formats... ...I trust that the 4646 record-jar format is fine. Actually I'm sure. We discussed XML vs. "STD 10 header style" in the last round, and also UTF-8 vs. NCRs. So far I haven't seen a compelling reason to change this. Folks who really want XML obviously can convert it. Converting it to a variant of CSV should be also trivial, ASCII offers 0x1C .. 0x1F separators if all else fails. Frank P.S:: Your lineend problem beats me, my two gawks (2.15pl5 and 3.0.6) don't care if it's Lf or CrLf. Officially it should be CrLf as in RFC 4234 (and as specified in RFC 4646). _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 22:51:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP9E6-0002CT-Si; Sun, 17 Sep 2006 22:51:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP9E5-0002CC-9Q for ltru@lists.ietf.org; Sun, 17 Sep 2006 22:51:17 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP9E3-0004Zu-CJ for ltru@lists.ietf.org; Sun, 17 Sep 2006 22:51:17 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8I2pECS000898 for ; Mon, 18 Sep 2006 11:51:14 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 3734_8c8ed684_46c0_11db_947f_0014221fa3c9; Mon, 18 Sep 2006 11:51:13 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35670) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 18 Sep 2006 11:51:14 +0900 Message-Id: <6.0.0.20.2.20060918111403.089f5270@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 18 Sep 2006 11:21:51 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: DOCTYPE ltru In-Reply-To: <450D6D1E.6AAB@xyzzy.claranet.de> References: <450B2F27.FD7@xyzzy.claranet.de> <20060917143445.GA10307@sources.org> <450D6D1E.6AAB@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 00:43 06/09/18, Frank Ellermann wrote: >Stephane Bortzmeyer wrote: > >> May be we should use the same vocabulary as the RFC 4646. For >> instance, you use "date" when the RFC uses (except for the >> element) "added". > >Yes, I wanted the same attribute name for all dates. With a >DTD some ABNF details are lost, I've used the name for a hint >about the real type (NMTOKEN isn't very precise for dates ;-) That's not the way XML is supposed to work. The names are supposed to say what something is, not to indicate the type. In a DTD, additional type information should go into comments. If you want to express/check these, use XML Schema or Relax or Schematron or a script. >> Or you use "tag" when the RFC uses subtag or tag, > >Same idea. In the version supporting ID-XREF-checks I could >keep "subtag" as is, and use "tag" only as attribute for the >grandfathered, redundant, prefix, and deprecated elements. > >> I do not see Preferred-value in your schema? > >It's the optional (#IMPLIED) "tag" in a element. If it's the preferred value, call it that. The idea of XML is that people understand as much as possible from the data and markup itself. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 22:51:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP9E2-0002C2-63; Sun, 17 Sep 2006 22:51:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP9E1-0002Bo-82 for ltru@lists.ietf.org; Sun, 17 Sep 2006 22:51:13 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP9Dz-0004ZU-Gc for ltru@lists.ietf.org; Sun, 17 Sep 2006 22:51:13 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8I2p73R000888 for ; Mon, 18 Sep 2006 11:51:09 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 4148_887b147c_46c0_11db_8cd0_0014221f2a2d; Mon, 18 Sep 2006 11:51:07 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35670) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 18 Sep 2006 11:51:11 +0900 Message-Id: <6.0.0.20.2.20060918111434.0899aec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 18 Sep 2006 11:14:49 +0900 To: Addison Phillips , Frank Ellermann From: Martin Duerst Subject: Re: [Ltru] Re: DOCTYPE ltru In-Reply-To: <450D858A.9030605@yahoo-inc.com> References: <008201c6d9b2$ebfd2600$6401a8c0@DGBP7M81> <450D3691.75B0@xyzzy.claranet.de> <450D858A.9030605@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 02:27 06/09/18, Addison Phillips wrote: >Capitalization doesn't mean anything in language tags and never has. We should fix it in the registry (via the reg process if possible, but certainly via 4645bis if not) Exactly my opinion, too. Regards, Martin. >Addison > >Frank Ellermann wrote: >> Doug Ewell wrote: >> >>>> with XML ID _latn is not _Latn. >> >>> It's capitalized that way because it was registered that way >>> under RFC 3066. >> Could we add this oddity as another exception (like zh-min) to >> 4645bis, or is it more straight forward if I try to update it >> directly using the language list ? >> Frank >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru > >-- >Addison Phillips >Globalization Architect -- Yahoo! Inc. > >Internationalization is an architecture. >It is not a feature. > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 23:18:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP9e7-0001Sf-6f; Sun, 17 Sep 2006 23:18:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP9e6-0001Rc-6K for ltru@ietf.org; Sun, 17 Sep 2006 23:18:10 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP9bg-0008Ar-VR for ltru@ietf.org; Sun, 17 Sep 2006 23:15:43 -0400 Received: from [10.72.76.233] (snvvpn2-10-72-76-c233.corp.yahoo.com [10.72.76.233]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8I3FQ0A015052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Sep 2006 20:15:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=o3hX91KpYz9JTW4xGaYnSu/mONs5sICjQRUFZ28g0AnpXtc8ybDqsTjP1G0j7Mxk Message-ID: <450E0F4E.1060509@yahoo-inc.com> Date: Sun, 17 Sep 2006 20:15:26 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] On deprecating 639-2 language collections References: <20060917222416.GA3003@ccil.org> <450DD598.9080404@yahoo-inc.com> <20060917233334.GE3003@ccil.org> In-Reply-To: <20060917233334.GE3003@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > >> #. Use specific language subtags or subtag sequences in preference to >> subtags for language collections. A "language collection" is a subtag >> derived from one of the ISO 639-2 codes that represents multiple related >> languages. For example, the code 'nai' represents "North American >> languages". The registry contains values for the specific languages >> represented by this collective code. For example 'xxx' (language1) and >> 'yyy' (language2). > > All well and good, except that it provides no definite guidance > on which language subtags are for collections. Deprecating them > does. I think I agree with deprecation. > >> Note that these languages are otherwise unrelated. > > Not always true. Indeed, I would say that the bulk of the 639-2 > collection code elements do in fact represent either genetic > subgroups or genetic subgroups with some languages or sub-subgroups > removed. No, but we'd pick our examples carefully. > >> I wouldn't have a problem with deprecating these codes. > > All right then. :-) > >> Should we provide a list of Prefix values? > > I don't understand. Do you mean a list of Preferred-Value values? > I'd say no; the collective subtag 'map', "Austronesian (Other)", > encompasses 1038 languages in Ethnologue-14, and the list may well > have grown since then. Furthermore, it is highly subject to change > as additional Austronesian languages are added or even removed due > to advances in knowledge. > Well, it was a thought :-). -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 17 23:26:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP9m1-00048Q-0M; Sun, 17 Sep 2006 23:26:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP9lz-00047m-8p for ltru@lists.ietf.org; Sun, 17 Sep 2006 23:26:19 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP9lx-0001dg-SL for ltru@lists.ietf.org; Sun, 17 Sep 2006 23:26:19 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GP9lo-0008Gl-0x for ltru@lists.ietf.org; Mon, 18 Sep 2006 05:26:08 +0200 Received: from pd9fba907.dip0.t-ipconnect.de ([217.251.169.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 05:26:08 +0200 Received: from nobody by pd9fba907.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 05:26:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Sep 2006 05:25:29 +0200 Organization: Lines: 16 Message-ID: <450E11A9.782B@xyzzy.claranet.de> References: <008201c6d9b2$ebfd2600$6401a8c0@DGBP7M81> <450D3691.75B0@xyzzy.claranet.de> <450D858A.9030605@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba907.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] Re: DOCTYPE ltru X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > Capitalization doesn't mean anything in language tags and > never has. Sure, I'm talking about a naive subtag to IDREF implementation for the registry based on some MUSTard in chapter 3.1: | Subtags whose 'Type' field is 'script' (in other words, | subtags defined by ISO 15924) MUST use titlecase. > We should fix it in the registry (via the reg process if > possible, but certainly via 4645bis if not) Okay. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 00:08:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPAQZ-0001dm-Sf; Mon, 18 Sep 2006 00:08:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPAQX-0001aP-Eh for ltru@ietf.org; Mon, 18 Sep 2006 00:08:13 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPADr-0005Ot-MY for ltru@ietf.org; Sun, 17 Sep 2006 23:55:10 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8I3t410019381 for ; Mon, 18 Sep 2006 12:55:04 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 4166_77451b54_46c9_11db_9a32_0014221f2a2d; Mon, 18 Sep 2006 12:55:03 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:39464) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 18 Sep 2006 12:55:08 +0900 Message-Id: <6.0.0.20.2.20060918120033.07504ab0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 18 Sep 2006 12:05:54 +0900 To: "Mark Davis" , "Addison Phillips" From: Martin Duerst Subject: Re: [Ltru] RFC 4646 production "grandfathered" considered harmful In-Reply-To: <30b660a20609171508s36585ea5r2311f0ac4c3cb2fe@mail.gmail.co m> References: <20060917061912.GB26073@ccil.org> <450D81D7.1070004@yahoo-inc.com> <30b660a20609171508s36585ea5r2311f0ac4c3cb2fe@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [chair hat on] I have seen at least four people approving the idea to list grandfathered/irregular tags explicitly, and nobody opposed. I think that in principle, we seem to have consensus to go this way, although some details may need to be worked out (see below). If anybody disagrees with this assessment, please state so soon. [chair hat off] I clearly thing that it is a bad idea to include somebody's name in a nonterminal of an ABNF. This is true both in general and also in this specific case. When Michael proposed and approved the tags listed below, they were not in any way illegal or irregular. Regards, Martin. At 07:08 06/09/18, Mark Davis wrote: >I do as well. Note that the BNF provides both checks of well-formedness (partial, because of repeating extensions), but also a division into semantic units. So we'd have to do something like: > > >grandfathered = irregular > > / 1*3ALPHA 1*2("-" (2*8alphanum)) ; registered grandfathered codes that are well-formed, but would not otherwise be valid > >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" > >We could also break them down into other divisions ;-) > > >grandfathered = "i-" irregular > / irregularEverson > > / 1*3ALPHA 1*2("-" (2*8alphanum)) ; registered grandfathered codes that are well-formed, but would not otherwise be valid >irregulari = "ami" / "bnn" / "default" / "enochian" / "hak" / "klingon" / "lux" / "mingo" / "navajo" / "pwn" / "tao" / "tay" / "tsu" >irregularEverson = "en-GB-oed" / "sgn-BE-fr" / "sgn-BE-nl" / "sgn-CH-de" >Mark #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 00:09:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPAS4-00020J-DN; Mon, 18 Sep 2006 00:09:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPAQa-0001WM-BJ for ltru@lists.ietf.org; Mon, 18 Sep 2006 00:08:16 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPADD-0005Md-Ki for ltru@lists.ietf.org; Sun, 17 Sep 2006 23:54:28 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPACx-0004gT-HB for ltru@lists.ietf.org; Mon, 18 Sep 2006 05:54:11 +0200 Received: from pd9fba907.dip0.t-ipconnect.de ([217.251.169.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 05:54:11 +0200 Received: from nobody by pd9fba907.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 05:54:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Sep 2006 05:52:34 +0200 Organization: Lines: 28 Message-ID: <450E1801.5597@xyzzy.claranet.de> References: <20060917061912.GB26073@ccil.org> <450D81D7.1070004@yahoo-inc.com> <30b660a20609171508s36585ea5r2311f0ac4c3cb2fe@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba907.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Ltru] Re: RFC 4646 production "grandfathered" considered harmful X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > grandfathered = "i-" irregular > / irregularEverson > / 1*3ALPHA 1*2("-" (2*8alphanum)) ; registered grandfathered codes that are well-formed, but would not otherwise be valid > irregulari = "ami" / "bnn" / "default" / "enochian" / "hak" / > "klingon" / "lux" / "mingo" / "navajo" / "pwn" / "tao" / "tay" / "tsu" > irregularEverson = "en-GB-oed" / "sgn-BE-fr" / "sgn-BE-nl" / > "sgn-CH-de" Splitting i-anything from the rest is fine, IMO unnecessary to enumerate them in the ABNF: Any decent parser could handle x-anything, it should be also able to handle i-anything. With that you'd get: grandfathered = i-legacy / irregular / ( 2*3ALPHA "-" 3*8ALPHA ) i-legacy = "i-" 3*8ALPHA irregular = sgn-legacy / "en-GB-oed" / "zh-min-nan" sgn-legacy = "sgn-" ( "BE-fr" / "BE-nl" / "CH-de" ) Cheating, zh-min-nan isn't really irregular, but together with en-GB-oed and it's the list of grandfathered tags with three parts. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 00:09:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPAS6-00021S-Hh; Mon, 18 Sep 2006 00:09:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPAQX-0001aP-OD for ltru@ietf.org; Mon, 18 Sep 2006 00:08:13 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPADr-0005P0-MY for ltru@ietf.org; Sun, 17 Sep 2006 23:55:10 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8I3t5iP005526 for ; Mon, 18 Sep 2006 12:55:05 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 4166_780ec9fe_46c9_11db_9a32_0014221f2a2d; Mon, 18 Sep 2006 12:55:04 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:39464) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 18 Sep 2006 12:55:09 +0900 Message-Id: <6.0.0.20.2.20060918124446.07506d80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 18 Sep 2006 12:46:33 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: UTF-8 In-Reply-To: <011e01c6da79$b7f17330$6401a8c0@DGBP7M81> References: <011e01c6da79$b7f17330$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 01:52 06/09/18, Doug Ewell wrote: >Martin Duerst wrote: > >>> John's "net-UTF-8" draft isn't ready, and I had some troubles to understand his last published version. >> >> That isn't very relevant, except that it suggests normalization to NFC, which I assume we would do anyway, and which is already an issue in the case of NCRs. > >Both the current Registry and the prototype 4646bis version are in NFC. Frankly, it hadn't occurred to me to do it any other way. > >This raises an interesting subpoint: I suppose either 4646bis or 4645bis should state explicitly that the Registry is in NFC. I agree. Frank said we should just use what the source uses, but officially, the soure in most cases still is paper. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 00:10:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPASq-0002cI-45; Mon, 18 Sep 2006 00:10:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPASp-0002cA-Gz for ltru@lists.ietf.org; Mon, 18 Sep 2006 00:10:35 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPASo-0007WP-7x for ltru@lists.ietf.org; Mon, 18 Sep 2006 00:10:35 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPASa-0007hk-EK for ltru@lists.ietf.org; Mon, 18 Sep 2006 06:10:20 +0200 Received: from pd9fba907.dip0.t-ipconnect.de ([217.251.169.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 06:10:20 +0200 Received: from nobody by pd9fba907.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 06:10:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Sep 2006 06:09:36 +0200 Organization: Lines: 19 Message-ID: <450E1C00.51A0@xyzzy.claranet.de> References: <006001c6d804$bb837060$6401a8c0@DGBP7M81> <3F8B0FE9D86E40178302D77C1CD8B8D3.MAI@home> <450A63A1.3A81@xyzzy.claranet.de> <20060917161753.GA25501@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba907.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: Registry Format X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > The output is not well-formed XML. Here is a patch: [...] > - print L A "' />" > + print L A "' >" Thanks, took me some time to find this after the W3C validator told me that my DTD doesn't allow the very first :-) > - } > \ No newline at end of file > + } Your gawk is rather pedantic with lineends. That "}" is the last line, why shouldn't it have a lineend ? Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 00:11:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPATc-00031Q-GR; Mon, 18 Sep 2006 00:11:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPATb-00031I-84 for ltru@ietf.org; Mon, 18 Sep 2006 00:11:23 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPATZ-0007cK-L1 for ltru@ietf.org; Mon, 18 Sep 2006 00:11:23 -0400 Received: by nf-out-0910.google.com with SMTP id n15so2957105nfc for ; Sun, 17 Sep 2006 21:11:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Z8mSYrw0Tz6OM9DIfDSx88CnzS7lIOPEr/MEz+tWtnBRNMDYM6Z/48kUTCd/r2k4mtc0FxVdK56S/RSgY5JhR7hgAHZ4V47+maBk4k+rojAErtl4XgKjsHii8ZiAoqiwPzv4FC5f89+71fuADJmGs5dCa+6lkJbnvTjy+GRqLhg= Received: by 10.48.162.15 with SMTP id k15mr16490724nfe; Sun, 17 Sep 2006 21:11:19 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Sun, 17 Sep 2006 21:11:19 -0700 (PDT) Message-ID: <30b660a20609172111g7e55e072w1060442f8fa9bcca@mail.gmail.com> Date: Sun, 17 Sep 2006 21:11:19 -0700 From: "Mark Davis" To: "Martin Duerst" Subject: Re: [Ltru] RFC 4646 production "grandfathered" considered harmful In-Reply-To: <6.0.0.20.2.20060918120033.07504ab0@localhost> MIME-Version: 1.0 References: <20060917061912.GB26073@ccil.org> <450D81D7.1070004@yahoo-inc.com> <30b660a20609171508s36585ea5r2311f0ac4c3cb2fe@mail.gmail.com> <6.0.0.20.2.20060918120033.07504ab0@localhost> X-Google-Sender-Auth: fda118657c4218a9 X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1116547272==" Errors-To: ltru-bounces@ietf.org --===============1116547272== Content-Type: multipart/alternative; boundary="----=_Part_170925_20969550.1158552679418" ------=_Part_170925_20969550.1158552679418 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline > I clearly thing that it is a bad idea to include somebody's name That was not intended seriously -- sorry for the confusion. Mark On 9/17/06, Martin Duerst wrote: > > [chair hat on] > I have seen at least four people approving the idea to list > grandfathered/irregular tags explicitly, and nobody opposed. > I think that in principle, we seem to have consensus to go this > way, although some details may need to be worked out (see below). > If anybody disagrees with this assessment, please state so soon. > > > [chair hat off] > I clearly thing that it is a bad idea to include somebody's name > in a nonterminal of an ABNF. This is true both in general and also > in this specific case. When Michael proposed and approved the > tags listed below, they were not in any way illegal or irregular. > > Regards, Martin. > > At 07:08 06/09/18, Mark Davis wrote: > >I do as well. Note that the BNF provides both checks of well-formedness > (partial, because of repeating extensions), but also a division into > semantic units. So we'd have to do something like: > > > > > >grandfathered = irregular > > > > / 1*3ALPHA 1*2("-" (2*8alphanum)) ; registered grandfathered > codes that are well-formed, but would not otherwise be valid > > > >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" > > > >We could also break them down into other divisions ;-) > > > > > >grandfathered = "i-" irregular > > / irregularEverson > > > > / 1*3ALPHA 1*2("-" (2*8alphanum)) ; registered grandfathered > codes that are well-formed, but would not otherwise be valid > >irregulari = "ami" / "bnn" / "default" / "enochian" / "hak" / "klingon" / > "lux" / "mingo" / "navajo" / "pwn" / "tao" / "tay" / "tsu" > >irregularEverson = "en-GB-oed" / "sgn-BE-fr" / "sgn-BE-nl" / "sgn-CH-de" > >Mark > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > ------=_Part_170925_20969550.1158552679418 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline > I clearly thing that it is a bad idea to include somebody's name

That was not intended seriously -- sorry for the confusion.

Mark

On 9/17/06, Martin Duerst <duerst@it.aoyama.ac.jp> wrote:
[chair hat on]
I have seen at least four people approving the idea to list
grandfathered/irregular tags explicitly, and nobody opposed.
I think that in principle, we seem to have consensus to go this
way, although some details may need to be worked out (see below).
If anybody disagrees with this assessment, please state so soon.


[chair hat off]
I clearly thing that it is a bad idea to include somebody's name
in a nonterminal of an ABNF. This is true both in general and also
in this specific case. When Michael proposed and approved the
tags listed below, they were not in any way illegal or irregular.

Regards,    Martin.

At 07:08 06/09/18, Mark Davis wrote:
>I do as well. Note that the BNF provides both checks of well-formedness (partial, because of repeating extensions), but also a division into semantic units. So we'd have to do something like:
>
>
>grandfathered = irregular
>
>            / 1*3ALPHA 1*2("-" (2*8alphanum)) ; registered grandfathered codes that are well-formed, but would not otherwise be valid
>
>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"
>
>We could also break them down into other divisions ;-)
>
>
>grandfathered = "i-" irregular
>            / irregularEverson
>
>            / 1*3ALPHA 1*2("-" (2*8alphanum)) ; registered grandfathered codes that are well-formed, but would not otherwise be valid
>irregulari = "ami" / "bnn" / "default" / "enochian" / "hak" / "klingon" / "lux" / "mingo" / "navajo" / "pwn" / "tao" / "tay" / "tsu"
>irregularEverson = "en-GB-oed" / "sgn-BE-fr" / "sgn-BE-nl" / "sgn-CH-de"
>Mark


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


------=_Part_170925_20969550.1158552679418-- --===============1116547272== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1116547272==-- From ltru-bounces@ietf.org Mon Sep 18 00:44:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPAzK-0006J7-82; Mon, 18 Sep 2006 00:44:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPAzI-0006Iz-WB for ltru@lists.ietf.org; Mon, 18 Sep 2006 00:44:09 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPAzH-0007PE-MB for ltru@lists.ietf.org; Mon, 18 Sep 2006 00:44:08 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPAz5-0004MR-Bs for ltru@lists.ietf.org; Mon, 18 Sep 2006 06:43:55 +0200 Received: from pd9fba907.dip0.t-ipconnect.de ([217.251.169.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 06:43:55 +0200 Received: from nobody by pd9fba907.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 06:43:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Sep 2006 06:43:22 +0200 Organization: Lines: 13 Message-ID: <450E23EA.3A10@xyzzy.claranet.de> References: <012001c6da7a$a95c46a0$6401a8c0@DGBP7M81> <450DF53A.380@xyzzy.claranet.de> <20060918013646.GK3003@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba907.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] Re: RFC 4646 production "grandfathered" considered harmful X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > How is zh-hakka different from zh-xiang or zh-guoyu (except > that the latter is deprecated)? zh-xiang etc. are not referenced anywhere. zh-hakka has a reference from i-hak, it appears in a Preferred-Value field. Similarly zh-cmn appears in the Preferred-Value of zh-guoyu, and at the moment there's no subtag cmn. A dangling pointer. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 00:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPB5l-0008R2-C2; Mon, 18 Sep 2006 00:50:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPB5k-0008Ne-IK for ltru@ietf.org; Mon, 18 Sep 2006 00:50:48 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPB5j-0002wk-A3 for ltru@ietf.org; Mon, 18 Sep 2006 00:50:48 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GPB5i-0006wv-ST; Mon, 18 Sep 2006 00:50:46 -0400 Date: Mon, 18 Sep 2006 00:50:46 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: RFC 4646 production "grandfathered" considered harmful Message-ID: <20060918045046.GM3003@ccil.org> References: <20060917061912.GB26073@ccil.org> <450D81D7.1070004@yahoo-inc.com> <30b660a20609171508s36585ea5r2311f0ac4c3cb2fe@mail.gmail.com> <450E1801.5597@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450E1801.5597@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > Splitting i-anything from the rest is fine, IMO unnecessary to > enumerate them in the ABNF: Any decent parser could handle > x-anything, it should be also able to handle i-anything. There's no reason to allow i-bogon to be well-formed. > Cheating, zh-min-nan isn't really irregular, but together with > en-GB-oed and it's the list of grandfathered tags > with three parts. Just so. The ABNF is syntactic, so I listed only the elements that do not match the "langtag" production. -- John Cowan cowan@ccil.org http://ccil.org/~cowan The present impossibility of giving a scientific explanation is no proof that there is no scientific explanation. The unexplained is not to be identified with the unexplainable, and the strange and extraordinary nature of a fact is not a justification for attributing it to powers above nature. --The Catholic Encyclopedia, s.v. "telepathy" (1913) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 00:50:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPB5r-00005Y-Gt; Mon, 18 Sep 2006 00:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPB5q-0008WL-Sm for ltru@ietf.org; Mon, 18 Sep 2006 00:50:54 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPB5p-0002x4-KE for ltru@ietf.org; Mon, 18 Sep 2006 00:50:54 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060918045048.MLPO7463.mta13.adelphia.net@DGBP7M81>; Mon, 18 Sep 2006 00:50:48 -0400 Message-ID: <01c601c6dade$0333d040$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <011e01c6da79$b7f17330$6401a8c0@DGBP7M81> <6.0.0.20.2.20060918124446.07506d80@localhost> Subject: Re: [Ltru] Re: UTF-8 Date: Sun, 17 Sep 2006 21:50:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > I agree. Frank said we should just use what the source uses, but > officially, the soure in most cases still is paper. As much for the archives as for Martin: The question of "use what the source uses" is a long-standing, divisive one. The sources for the 4646 Registry were electronic: code lists found on the home pages of the ISO MA's and on the UNSD site. Sometimes these appeared inconsistent, with themselves and particularly with each other, on things like apostrophe usage. Sometimes they yielded bizarre results, like the acute accent (U+00B4) used in the name Gwich'in. There are WG members (and ietf-languages contributors) who feel very strongly that the Description fields in the Registry must match the source standards exactly, to enable automated cross-referencing and generally to avoid arbitrariness. Then there are WG members (and ietf-languages contributors) who feel equally strongly that we should be able to improve on the names, either typographically or to improve clarity and avoid ambiguity. These two groups are at polar opposites and the only way to satisfy both is to admit both Descriptions, even when the end result seems preposterous. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 00:55:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPBAj-0001r6-HV; Mon, 18 Sep 2006 00:55:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPBAi-0001qy-1C for ltru@lists.ietf.org; Mon, 18 Sep 2006 00:55:56 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPBAg-0004F5-N6 for ltru@lists.ietf.org; Mon, 18 Sep 2006 00:55:56 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPBAV-00065V-RD for ltru@lists.ietf.org; Mon, 18 Sep 2006 06:55:43 +0200 Received: from pd9fba907.dip0.t-ipconnect.de ([217.251.169.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 06:55:43 +0200 Received: from nobody by pd9fba907.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 06:55:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Sep 2006 06:53:15 +0200 Organization: Lines: 50 Message-ID: <450E263B.2B99@xyzzy.claranet.de> References: <6.0.0.20.2.20060918111628.08943ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba907.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: [Ltru] Re: Fwd: Re: [OT] DOCTYPE ltru X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > Frank, can you post your answer to the list, too? Date: Sun, 17 Sep 2006 22:22:54 +0200 To: Martin Duerst Martin Duerst wrote: > As a co-chair, I marked this off-topic, unless I > misunderstood you to make this as a proposal for > the actual registry. It's what we'd get if we drop record-jar, and what I'd propose if we go for UTF-8. Actually it belongs to the thread "Registry-format", where Debbie wrote that record-jar isn't human readable. I think it's fine, that's why I checked my theory "writing an awk script is trivial". It really is trivial, finding a simple DTD for XML output is the most exciting part. As a side-effect I have now an output format allowing to validate registries with any XML validator. > change the DOCTYPE and root element from 'ltru' to > something like 'LanguageSubtagRegistry'. Done, see > 'date' attributes should be changed to the more >informative 'added'. For now I stick to date, because I use it for all registry dates, not only Added fields, also for Deprecated and File-Date. > I'd done some of the element/attribute decisions > differently, but that's not a big issue. Probably a matter of taste, DTD validators are not very smart, but they can do something with ID, IDREF, IDREFS, and NMTOKEN. Some other sanity checks are in the script. Actually the script could check references directly, and also verify dates, but it's nice that the XML output now works with the W3C validator. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 01:00:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPBFK-0003d8-7B; Mon, 18 Sep 2006 01:00:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPBFI-0003au-Tr for ltru@ietf.org; Mon, 18 Sep 2006 01:00:40 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPBFH-00061y-Mw for ltru@ietf.org; Mon, 18 Sep 2006 01:00:40 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060918050038.DGVH10468.mta9.adelphia.net@DGBP7M81>; Mon, 18 Sep 2006 01:00:38 -0400 Message-ID: <01cf01c6dadf$6304d0e0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <010201c6da1a$3405ad70$6401a8c0@DGBP7M81> <6.0.0.20.2.20060917161407.088b7ce0@localhost> Subject: Re: [Ltru] Process for creating 4646bis Registry Date: Sun, 17 Sep 2006 22:00:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > As a co-chair, I strongly suggest that you submit your text below and > your data as an Internet-Draft as soon as possible. This is NOT > because I want us to meet the deadline in September, but because this > is the way work is done in the IETF. Also, I'd like to see how well > the Internet-Drafts system takes this (almost) mega-draft. I shall get to it, then. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 01:09:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPBNq-0006RG-Lj; Mon, 18 Sep 2006 01:09:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPBNo-0006Ps-BQ for ltru@ietf.org; Mon, 18 Sep 2006 01:09:28 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPBNn-0002Gn-3V for ltru@ietf.org; Mon, 18 Sep 2006 01:09:28 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060918050926.DKLI10468.mta9.adelphia.net@DGBP7M81>; Mon, 18 Sep 2006 01:09:26 -0400 Message-ID: <01d101c6dae0$9d715ea0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <005301c6d94a$201174a0$6401a8c0@DGBP7M81> <6.0.0.20.2.20060917165059.08a0ed10@localhost> Subject: Re: [Ltru] Re: UTF-8 Date: Sun, 17 Sep 2006 22:09:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > I agree with the fact that we must be able to deliver UTF-8 to IANA. I > don't think it necessarily needs to be an I-D. I easily can immagine > that you publish an I-D containing just a pointer to an URI and an MD5 > for checking. Can you check into this? It would be nice to say up front what the I-D is for, rather than writing it as "This contains the initial contents of the Registry" and then having the RFC Editor remove the fun part. >> 2. We have to maintain compatibility with the existing format, which >> means we must continue to escape the ampersand as & if one >> should ever find its way into the Registry. > > As I have said in another mail, I'd agree with the continued need for > escaping the sequence "&#x", but I don't see any practical relevance > for it; we can simply disallow it. For just "&", it may cause a > parsing problem for older software the same way UTF-8 may cause a > parsing problem, so I don't see the need to keep escaping it. The ABNF in 4646 says the ampersand is not a valid character and must be escaped, because it introduces the &#x sequences. I'm feeling lazy. Can someone else verify this, and speak to the impact of allowing a character that we previously did not allow? -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 01:28:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPBgJ-0004lP-0a; Mon, 18 Sep 2006 01:28:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPBgH-0004lG-NI for ltru@ietf.org; Mon, 18 Sep 2006 01:28:33 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPBgF-0005CX-F3 for ltru@ietf.org; Mon, 18 Sep 2006 01:28:33 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060918052826.DTAM10468.mta9.adelphia.net@DGBP7M81> for ; Mon, 18 Sep 2006 01:28:26 -0400 Message-ID: <01d401c6dae3$451ce230$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 17 Sep 2006 22:28:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > The other possibility is to say whatever the sources say. I didn't > note that you modified the source descriptions in some way. Please > don't do this without a rule for it in 4646bis. I didn't. Having said that, I would really like the WG to come to a FORMAL decision, certified by a co-chair, on this whole Description thing. We should not have text in 4646bis that talks about the Description field being non-normative, only for identification purposes, only to indicate the meaning of the subtag, able to be broadened, etc., and at the same time be required to keep the exact ISO-originated reference name, warts and ambiguity and weird acute accents and all. I'm not sure I even care any more which path we choose, but we cannot have it both ways. > If that's the case they should most definitely say so. But I don't > see the point, just copy what the sources say as long as it's an > assigned code-point for a character. Don't forget about variant subtags registered by ietf-languages. Those don't have "sources" in the sense you're thinking of. > Good that we didn't introduce an MES-1 restriction for 4646 :-) We didn't add any restriction, and there was a reason for that. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 01:49:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPC0J-0003aL-PH; Mon, 18 Sep 2006 01:49:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPC0I-0003XV-0N for ltru@ietf.org; Mon, 18 Sep 2006 01:49:14 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPBom-0000RB-L4 for ltru@ietf.org; Mon, 18 Sep 2006 01:37:24 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060918053719.TTBF27224.mta10.adelphia.net@DGBP7M81> for ; Mon, 18 Sep 2006 01:37:19 -0400 Message-ID: <01d801c6dae4$82eac360$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 17 Sep 2006 22:37:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Ltru] Re: DOCTYPE ltru X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> Capitalization doesn't mean anything in language tags and never has. > > Sure, I'm talking about a naive subtag to IDREF implementation for the > registry based on some MUSTard in chapter 3.1: > > | Subtags whose 'Type' field is 'script' (in other words, > | subtags defined by ISO 15924) MUST use titlecase. "yi-latn" is not a subtag, it's a redundant tag: RFC 4645 section 2, point 7: > 7. Tags in the [RFC3066] registry that were not deprecated, > consisted entirely of subtags already in this document, and > have the correct form and format for tags defined by [RFC4646] > were converted to records of type "redundant" in the ILSR. > For example, "zh-Hant" is now defined by [RFC4646] because > 'zh' is an [ISO639-1] code element and 'Hant' is an [ISO15924] > code element, and both are defined as subtags in the ILSR. I guess the question is whether "yi-latn" does or does not have the "correct format," taking its capitalization into account. I note that nobody objected to it during the rather long WG and IETF review periods. >> We should fix it in the registry (via the reg process if possible, >> but certainly via 4645bis if not) > > Okay. Whatever happened to "fidelity with the source standards at all costs"? The RFC 3066 tag registry is the source standard for redundant tags. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 01:53:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPC4d-0005og-KQ; Mon, 18 Sep 2006 01:53:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPC4b-0005oV-Pu for ltru@ietf.org; Mon, 18 Sep 2006 01:53:41 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPC4a-0004w0-G2 for ltru@ietf.org; Mon, 18 Sep 2006 01:53:41 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060918055339.XUYP28624.mta11.adelphia.net@DGBP7M81> for ; Mon, 18 Sep 2006 01:53:39 -0400 Message-ID: <01dc01c6dae6$cb0ae560$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 17 Sep 2006 22:53:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [Ltru] zh-hakka (was: Re: RFC 4646 production "grandfathered" considered harmful) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > John Cowan wrote: > >> How is zh-hakka different from zh-xiang or zh-guoyu (except that the >> latter is deprecated)? > > zh-xiang etc. are not referenced anywhere. zh-hakka has a reference > from i-hak, it appears in a Preferred-Value field. I'm not seeing the problem that Frank is seeing at all. 4646 Registry: Type: grandfathered Tag: i-hak Description: Hakka Added: 1999-01-31 Preferred-Value: zh-hakka Deprecated: 2000-01-10 Type: grandfathered Tag: zh-hakka Description: Hakka Added: 1999-12-18 The grandfathered tag "i-hak" is deprecated in favor of the grandfathered tag "zh-hakka". 4646bis Registry: Type: grandfathered Tag: i-hak Description: Hakka Added: 1999-01-31 Preferred-Value: zh-hakka Deprecated: 2000-01-10 Type: grandfathered Tag: zh-hakka Description: Hakka Added: 1999-12-18 Preferred-Value: zh-hak Deprecated: 2007-01-01 Comments: replaced by ISO code hak Type: extlang Subtag: hak Description: Chinese, Hakka Added: 2007-01-01 Prefix: zh The grandfathered tag "i-hak" is deprecated in favor of the grandfathered tag "zh-hakka", which in turn is deprecated by the generative tag "zh-hak", composed of subtags "zh" and "hak". What is irregular or ill-advised about this? > Similarly zh-cmn appears in the Preferred-Value of zh-guoyu, and at > the moment there's no subtag cmn. A dangling pointer. 4646 Registry: Type: grandfathered Tag: zh-guoyu Description: Mandarin or Standard Chinese Added: 1999-12-18 Preferred-Value: zh-cmn Deprecated: 2005-07-15 Type: grandfathered Tag: zh-cmn Description: Mandarin Chinese Added: 2005-07-15 The grandfathered tag "zh-guoyu" is deprecated in favor of the grandfathered tag "zh-cmn". 4646bis Registry: Type: grandfathered Tag: zh-guoyu Description: Mandarin or Standard Chinese Added: 1999-12-18 Preferred-Value: zh-cmn Deprecated: 2005-07-15 Comments: replaced by ISO code cmn Type: extlang Subtag: cmn Description: Chinese, Mandarin Added: 2007-01-01 Prefix: zh Type: redundant Tag: zh-cmn Description: Mandarin Chinese Added: 2005-07-15 The grandfathered tag "zh-guoyu" is deprecated in favor of the generative tag "zh-cmn", composed of subtags "zh" and "cmn". Coincidentally, there is also a redundant tag "zh-cmn" which is syntactically and semantically identical to the generative tag "zh-cmn". What is irregular or ill-advised about this? -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 02:04:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPCFA-0000vI-Bq; Mon, 18 Sep 2006 02:04:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPCF9-0000vD-6c for ltru@lists.ietf.org; Mon, 18 Sep 2006 02:04:35 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPCF7-0005nF-TM for ltru@lists.ietf.org; Mon, 18 Sep 2006 02:04:35 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPCEw-0000LW-L0 for ltru@lists.ietf.org; Mon, 18 Sep 2006 08:04:22 +0200 Received: from pd9fba907.dip0.t-ipconnect.de ([217.251.169.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 08:04:22 +0200 Received: from nobody by pd9fba907.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 08:04:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Sep 2006 08:03:05 +0200 Organization: Lines: 28 Message-ID: <450E3699.3E56@xyzzy.claranet.de> References: <005301c6d94a$201174a0$6401a8c0@DGBP7M81> <6.0.0.20.2.20060917165059.08a0ed10@localhost> <01d101c6dae0$9d715ea0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba907.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > The ABNF in 4646 says the ampersand is not a valid character and must > be escaped, because it introduces the &#x sequences. I'm feeling lazy. > Can someone else verify this, Of course, it's in the production, and in the prose. > the impact of allowing a character that we previously did not allow? I refuse to abuse my crystal-ball today. Registry converters to XML have to replace "<" by "<", and while they're at it ">" to ">" isn't wrong. UTF-8-jar converters to XML would use UTF-8 as encoding, and replace "&" by "&" before the "<" to "<" and ">" to ">". They could throw an error for "&#x", or they can try to get it right: "&#x" to ASCII SUB, other "&" to "&", SUB back to "&#x", after they've checked that it's a plausible NCR. Or they could replace the NCR by UTF-8. The constant thing over all programming languages: The code has to be updated. Not difficult, a minor technical change. The "keep NCR as is" trick works only for XML as output format. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 02:20:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPCUP-0006RI-5B; Mon, 18 Sep 2006 02:20:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPCUN-0006Px-HK for ltru@ietf.org; Mon, 18 Sep 2006 02:20:19 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPCUI-0007tC-TQ for ltru@ietf.org; Mon, 18 Sep 2006 02:20:19 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Sun, 17 Sep 2006 23:19:55 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Sun, 17 Sep 2006 23:19:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 17 Sep 2006 23:19:42 -0700 Message-ID: In-Reply-To: <30b660a20609161145h47e63289n1f9a96b9fc682c34@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISO 15924 process Thread-Index: AcbZwF9FQoZd7hLkQzOU4q0Vi/PuDwBKVy0A From: Peter Constable To: X-OriginalArrivalTime: 18 Sep 2006 06:19:55.0206 (UTC) FILETIME=[7550A660:01C6DAEA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Subject: [Ltru] ISO 15924 process X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1290406673==" Errors-To: ltru-bounces@ietf.org --===============1290406673== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DAEA.751FE578" ------_=_NextPart_001_01C6DAEA.751FE578 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFyazoNCg0KIA0KDQpZb3UgbWVudGlvbmVkIHlvdSB3ZXJlIGFuIG9ic2VydmVyIHRvIHRoZSBJ U08gMTU5MjQgcHJvY2Vzcy4gQ2FuIHlvdSBmaWxsIHVzIGluIG9uIHRoYXQgcHJvY2Vzcz8NCg0K IA0KDQotICAgICAgICAgIENhbiB0aGUgcHVibGljIG9ic2VydmUgdGhlIHByb2Nlc3MsIG9yIGFy ZSB5b3UganVzdCBvbmUgb2YgdGhlIGZpdmUgbm9uLXZvdGluZyBvYnNlcnZlcnMgaW4gYW4gb3Ro ZXJ3aXNlIGNsb3NlZCBwcm9jZXNzPw0KDQotICAgICAgICAgIFdobyBhcmUgdGhlIHJlcHMgZnJv bSBlYWNoIG9mIFRDNDYsIFRDMzcsIEpUQzEvU0MyIGFuZCB0aGUgUkE/DQoNCiANCg0KSnVzdCBj dXJpb3Vz4oCmDQoNCiANCg0KIA0KDQpQZXRlcg0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCkZyb206IE1hcmsgRGF2aXMgW21haWx0bzptYXJrLmRhdmlzQGljdS1w cm9qZWN0Lm9yZ10gDQpTZW50OiBTYXR1cmRheSwgU2VwdGVtYmVyIDE2LCAyMDA2IDExOjQ2IEFN DQpUbzogTWFydGluIEhvc2tlbg0KQ2M6IERvdWcgRXdlbGw7IExUUlUgV29ya2luZyBHcm91cA0K U3ViamVjdDogUmU6IFtMdHJ1XSBSZTogc2NyaXB0IHRhZyBmb3IgSVBBDQoNCiANCg0KSSBnZW5l cmFsbHkgYWdyZWUgd2l0aCBBZGRpc29uJ3MgY29tbWVudHMuIEEgY291cGxlIG9mIGZ1cnRoZXIg aXRlbXMuDQoNCjEuIFByb2NlZHVyYWxseSwgdGhlIHBvc3NpYmlsaXR5IG9mIGdldHRpbmcgYW4g SVBBIHNjcmlwdCB2YXJpYW50IGlzIG5vdCB6ZXJvLiBJdCB3YXMgcHJvcG9zZWQsIHRoZXJlIHdh cyB2ZXJ5IGxpdHRsZSBkaXNjdXNzaW9uLCBhbmQgZGlzbWlzc2VkIHdpdGhvdXQgYSBsb3Qgb2Yg ZGlzY3Vzc2lvbiAoSSdtIGp1c3QgYW4gb2JzZXJ2ZXIpLiBTbyBpZiBhIG1vcmUgcmVhc29uZWQg ZG9jdW1lbnQgaXMgcHJlc2VudGVkIHRoZXJlIGNvdWxkIGJlIGRpZmZlcmVudCByZXN1bHRzLiBV bmxpa2Ugb3RoZXIgY2FzZXMsIGl0IGlzIG5vdCB1cCB0byBvbmUgcGVyc29uIGNhcHJpY2lvdXNu ZXNzLiANCg0KMi4gSSB0aGluayB0aGUgcHJpdmF0ZSB1c2UgY29kZXMgKGZvciBzY3JpcHQsIGV0 YykgYXJlIG1pc3VuZGVyc3Rvb2QuIElmIGFuIGF1dGhvcml0eSBkZXNpZ25hdGVzIGEgY29kZSBh cyBwcml2YXRlIHVzZSBjb2RlLCB0aGF0IG1lYW5zIHRoYXQgaXQgaXMgcmVjb2duaXplZCBhcyBh IHZhbGlkIGNvZGUsIGJ1dCB0aGF0IGF1dGhvcml0eSBkb2Vzbid0IGF0dGFjaCBhIG1lYW5pbmcg dG8gaXQsIGFuZCBuZXZlciB3aWxsLg0KDQpJdCBkb2VzIG5vdCBtZWFuIHRoYXQgbm9ib2R5IGVs c2UgY2FuIGF0dGFjaCBhIG1lYW5pbmcgdG8gaXQgLS0gaWYgdGhhdCB3ZXJlIHRoZSBjYXNlIGl0 IHdvdWxkIGJlIGNvbXBsZXRlbHkgcG9pbnRsZXNzIHRvIGhhdmUgcHJpdmF0ZSB1c2UgY29kZXMu IEZvciBleGFtcGxlLCB0aGUgVW5pY29kZSBDb25zb3J0aXVtIGRlZmluZXMgYSBtZWFuaW5nIGZv ciBRYWFpICggaHR0cDovL3d3dy51bmljb2RlLm9yZy9yZXBvcnRzL3RyMjQvKS4gQW55IGFwcGxp Y2F0aW9uIGNvbmZvcm1hbnQgdG8gdGhlIFVuaWNvZGUgU3RhbmRhcmQgbXVzdCBpbnRlcnByZXQg UWFhaSBhcyBhcHBsaWVkIHdpdGggdGhhdCBtZWFuaW5nLiBJdCBhbHNvIGF0dGFjaGVzIG1lYW5p bmcgdG8gY2VydGFpbiBwcml2YXRlIHVzZSB0YWdzIGluIENMRFIgKExETUwpLCBub3RhYmx5IGZv ciBzb21lIHJlZ2lvbiBjb2RlczogDQoNClFPDQoNCk91dGx5aW5nIE9jZWFuaWENCg0KUVUNCg0K RXVyb3BlYW4gVW5pb24NCg0KWloNCg0KVW5rbm93biBvciBJbnZhbGlkIFRlcnJpdG9yeQ0KDQpC dXQgaXQgb25seSB0YWtlcyBwYXJ0IG9mIHRoZSByYW5nZTogIlRoZSBwcml2YXRlIHVzZSBjb2Rl cyBmcm9tIFhBLi5YWiB3aWxsIG5ldmVyIGJlIHVzZWQgYnkgQ0xEUiwgYW5kIGFyZSB0aHVzIHNh ZmUgZm9yIHVzZSBmb3Igb3RoZXIgcHVycG9zZXMgYnkgYXBwbGljYXRpb25zIHVzaW5nIENMRFIg ZGF0YSIuDQoNCkl0IHdvdWxkIGJlIHBvc3NpYmxlIGZvciBSRkM0NjQ2YmlzIHRvIGRlZmluZSBh IHJhbmdlIG9mIHByaXZhdGUgdXNlIGNvZGVzIHRoYXQgaXQgd2lsbCB1c2UuIFRoaXMgd291bGQg bmVlZCB0byBiZSB2ZXJ5IGNhcmVmdWxseSBkb25lLCBhbmQgd2UgbWlnaHQgZGVjaWRlIHRoYXQg aXQgaXMgbm90IGFwcHJvcHJpYXRlLCBidXQgaXQgaXMgY2VydGFpbmx5IGEgcG9zc2liaWxpdHku IA0KDQpNYXJrDQoNCg== ------_=_NextPart_001_01C6DAEA.751FE578 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1HZW5lcmF0b3IgY29u dGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNv XT4NCjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2Jl aGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNW TUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwh W2VuZGlmXS0tPjxvOlNtYXJ0VGFnVHlwZQ0KIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIiBuYW1lPSJQbGFjZVR5cGUiLz4NCjxvOlNtYXJ0 VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNt YXJ0dGFncyINCiBuYW1lPSJQbGFjZU5hbWUiLz4NCjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1 cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyINCiBuYW1lPSJw bGFjZSIvPg0KPCEtLVtpZiAhbXNvXT4NCjxzdHlsZT4NCnN0MVw6KntiZWhhdmlvcjp1cmwoI2Rl ZmF1bHQjaWVvb3VpKSB9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+DQo8c3R5bGU+DQo8IS0tDQog LyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2Rp bmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseTpBcmlhbDsNCgljb2xvcjpuYXZ5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5TZWN0aW9u MQ0KCXtwYWdlOlNlY3Rpb24xO30NCiAvKiBMaXN0IERlZmluaXRpb25zICovDQogQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6MzA4NjMwODU0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMTU1NjcxMzU2IC0yMDg0NTY3Mzc2IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OlNp bVN1bjt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQotLT4NCjwvc3R5bGU+DQoNCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJs dWUgdmxpbms9Ymx1ZT4NCg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5NYXJrOjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIg Y29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9u dC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9 QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpuYXZ5Jz5Zb3UgbWVudGlvbmVkIHlvdSB3ZXJlIGFuIG9ic2VydmVyIHRvIHRoZQ0KSVNP IDE1OTI0IHByb2Nlc3MuIENhbiB5b3UgZmlsbCB1cyBpbiBvbiB0aGF0IHByb2Nlc3M/PG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtm b250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW47dGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExp c3RzXT48Zm9udA0Kc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDsNCmNvbG9yOm5hdnknPjxzcGFuIHN0eWxl PSdtc28tbGlzdDpJZ25vcmUnPi08Zm9udCBzaXplPTEgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3Bhbg0Kc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48 L3NwYW4+PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+PHNwYW4gZGlyPUxUUj48Zm9udCBzaXplPTIN CmNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpBcmlhbDsNCmNvbG9yOm5hdnknPkNhbiB0aGUgcHVibGljIG9ic2VydmUgdGhlIHBy b2Nlc3MsIG9yIGFyZSB5b3UganVzdCBvbmUgb2YgdGhlIGZpdmUNCm5vbi12b3Rpbmcgb2JzZXJ2 ZXJzIGluIGFuIG90aGVyd2lzZSBjbG9zZWQgcHJvY2Vzcz88bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDou NWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PGZvbnQNCnNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7DQpjb2xvcjpuYXZ5Jz48c3Bh biBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4tPGZvbnQgc2l6ZT0xIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4NCnN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCFbZW5kaWZdPjxzcGFuIGRpcj1MVFI+PGZvbnQg c2l6ZT0yDQpjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6QXJpYWw7DQpjb2xvcjpuYXZ5Jz5XaG8gYXJlIHRoZSByZXBzIGZyb20g ZWFjaCBvZiBUQzQ2LCBUQzM3LCBKVEMxL1NDMiBhbmQgdGhlIFJBPzxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNv bG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFy aWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29s b3I6bmF2eSc+SnVzdCBjdXJpb3Vz4oCmPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5 Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIg Y29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9u dC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+UGV0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1B cmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2Nv bG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCc+DQoNCjxkaXY+DQoNCjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNl bnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxmb250IHNpemU9Mw0KZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+DQoNCjxociBzaXplPTIg d2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0YWJpbmRleD0tMT4NCg0KPC9zcGFuPjwvZm9udD48 L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxmb250IHNpemU9MiBmYWNlPVRhaG9tYT48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OlRhaG9tYTtmb250LXdl aWdodDpib2xkJz5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9Mg0KZmFjZT1UYWhv bWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hJz4gTWFy ayBEYXZpcw0KW21haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZ10gPGJyPg0KPGI+PHNw YW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlNlbnQ6PC9zcGFuPjwvYj4gU2F0dXJkYXksIFNl cHRlbWJlciAxNiwgMjAwNg0KMTE6NDYgQU08YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWln aHQ6Ym9sZCc+VG86PC9zcGFuPjwvYj4gTWFydGluIEhvc2tlbjxicj4NCjxiPjxzcGFuIHN0eWxl PSdmb250LXdlaWdodDpib2xkJz5DYzo8L3NwYW4+PC9iPiBEb3VnIEV3ZWxsOyBMVFJVIFdvcmtp bmcgR3JvdXA8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U3ViamVjdDo8 L3NwYW4+PC9iPiBSZTogW0x0cnVdIFJlOiBzY3JpcHQgdGFnDQpmb3IgSVBBPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIu MHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToNCjEyLjBwdCc+SSBnZW5lcmFsbHkgYWdyZWUgd2l0aCA8c3QxOnBsYWNlIHc6c3Q9 Im9uIj5BZGRpc29uPC9zdDE6cGxhY2U+J3MNCmNvbW1lbnRzLiBBIGNvdXBsZSBvZiBmdXJ0aGVy IGl0ZW1zLjxicj4NCjxicj4NCjEuIFByb2NlZHVyYWxseSwgdGhlIHBvc3NpYmlsaXR5IG9mIGdl dHRpbmcgYW4gSVBBIHNjcmlwdCB2YXJpYW50IGlzIG5vdCB6ZXJvLg0KSXQgd2FzIHByb3Bvc2Vk LCB0aGVyZSB3YXMgdmVyeSBsaXR0bGUgZGlzY3Vzc2lvbiwgYW5kIGRpc21pc3NlZCB3aXRob3V0 IGEgbG90DQpvZiBkaXNjdXNzaW9uIChJJ20ganVzdCBhbiBvYnNlcnZlcikuIFNvIGlmIGEgbW9y ZSByZWFzb25lZCBkb2N1bWVudCBpcw0KcHJlc2VudGVkIHRoZXJlIGNvdWxkIGJlIGRpZmZlcmVu dCByZXN1bHRzLiBVbmxpa2Ugb3RoZXIgY2FzZXMsIGl0IGlzIG5vdCB1cCB0bw0Kb25lIHBlcnNv biBjYXByaWNpb3VzbmVzcy4gPGJyPg0KPGJyPg0KMi4gSSB0aGluayB0aGUgcHJpdmF0ZSB1c2Ug Y29kZXMgKGZvciBzY3JpcHQsIGV0YykgYXJlIG1pc3VuZGVyc3Rvb2QuIElmIGFuDQphdXRob3Jp dHkgZGVzaWduYXRlcyBhIGNvZGUgYXMgcHJpdmF0ZSB1c2UgY29kZSwgdGhhdCBtZWFucyB0aGF0 IGl0IGlzDQpyZWNvZ25pemVkIGFzIGEgdmFsaWQgY29kZSwgYnV0IDxiPjxpPjxzcGFuIHN0eWxl PSdmb250LXdlaWdodDpib2xkO2ZvbnQtc3R5bGU6DQppdGFsaWMnPnRoYXQgPC9zcGFuPjwvaT48 L2I+YXV0aG9yaXR5IGRvZXNuJ3QgYXR0YWNoIGEgbWVhbmluZyB0byBpdCwgPGk+PHNwYW4NCnN0 eWxlPSdmb250LXN0eWxlOml0YWxpYyc+YW5kIG5ldmVyIHdpbGwuPGJyPg0KPGJyPg0KPC9zcGFu PjwvaT5JdCBkb2VzIG5vdCBtZWFuIHRoYXQgbm9ib2R5IGVsc2UgY2FuIGF0dGFjaCBhIG1lYW5p bmcgdG8gaXQgLS0gaWYNCnRoYXQgd2VyZSB0aGUgY2FzZSBpdCB3b3VsZCBiZSBjb21wbGV0ZWx5 IHBvaW50bGVzcyB0byBoYXZlIHByaXZhdGUgdXNlIGNvZGVzLg0KRm9yIGV4YW1wbGUsIHRoZSBV bmljb2RlIENvbnNvcnRpdW0gZGVmaW5lcyBhIG1lYW5pbmcgZm9yIFFhYWkgKCA8YQ0KaHJlZj0i aHR0cDovL3d3dy51bmljb2RlLm9yZy9yZXBvcnRzL3RyMjQvIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL3d3dy51bmljb2RlLm9yZy9yZXBvcnRzL3RyMjQvPC9hPikuDQpBbnkgYXBwbGljYXRpb24g Y29uZm9ybWFudCB0byB0aGUgVW5pY29kZSBTdGFuZGFyZCBtdXN0IGludGVycHJldCBRYWFpIGFz DQphcHBsaWVkIHdpdGggdGhhdCBtZWFuaW5nLiBJdCBhbHNvIGF0dGFjaGVzIG1lYW5pbmcgdG8g Y2VydGFpbiBwcml2YXRlIHVzZSB0YWdzDQppbiBDTERSIChMRE1MKSwgbm90YWJseSBmb3Igc29t ZSByZWdpb24gY29kZXM6IDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjx0YWJsZSBj bGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MSBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTAN CiBzdHlsZT0nbWFyZ2luLWxlZnQ6Ni4wcHQnPg0KIDx0cj4NCiAgPHRkIHN0eWxlPSdwYWRkaW5n OjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Jz4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6Ni4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjsNCiAgbWFyZ2luLWJvdHRv bTo2LjBwdDttYXJnaW4tbGVmdDowaW4nPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuDQogIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5RTzxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQogIDwvdGQ+DQogIDx0ZCBzdHlsZT0ncGFkZGluZzoxLjVwdCAxLjVwdCAx LjVwdCAxLjVwdCc+DQogIDxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OjYuMHB0O21hcmdpbi1yaWdodDowaW47DQogIG1hcmdpbi1ib3R0b206Ni4wcHQ7bWFyZ2lu LWxlZnQ6MGluJz48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0KICBz dHlsZT0nZm9udC1zaXplOjEyLjBwdCc+T3V0bHlpbmcgPHN0MTpwbGFjZSB3OnN0PSJvbiI+T2Nl YW5pYTwvc3QxOnBsYWNlPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQogIDwvdGQ+DQog PC90cj4NCiA8dHI+DQogIDx0ZCBzdHlsZT0ncGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVw dCc+DQogIDxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjYuMHB0 O21hcmdpbi1yaWdodDowaW47DQogIG1hcmdpbi1ib3R0b206Ni4wcHQ7bWFyZ2luLWxlZnQ6MGlu Jz48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0KICBzdHlsZT0nZm9u dC1zaXplOjEyLjBwdCc+UVU8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KICA8L3RkPg0K ICA8dGQgc3R5bGU9J3BhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQnPg0KICA8cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDo2LjBwdDttYXJnaW4tcmlnaHQ6 MGluOw0KICBtYXJnaW4tYm90dG9tOjYuMHB0O21hcmdpbi1sZWZ0OjBpbic+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQn PkV1cm9wZWFuIFVuaW9uPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCiAgPC90ZD4NCiA8 L3RyPg0KIDx0cj4NCiAgPHRkIHN0eWxlPSdwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0 Jz4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6Ni4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjsNCiAgbWFyZ2luLWJvdHRvbTo2LjBwdDttYXJnaW4tbGVmdDowaW4n Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuDQogIHN0eWxlPSdmb250 LXNpemU6MTIuMHB0Jz5aWjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQogIDwvdGQ+DQog IDx0ZCBzdHlsZT0ncGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCc+DQogIDxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjYuMHB0O21hcmdpbi1yaWdodDow aW47DQogIG1hcmdpbi1ib3R0b206Ni4wcHQ7bWFyZ2luLWxlZnQ6MGluJz48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0KICBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+ VW5rbm93biBvciA8c3QxOnBsYWNlIHc6c3Q9Im9uIj48c3QxOlBsYWNlTmFtZQ0KICAgdzpzdD0i b24iPkludmFsaWQ8L3N0MTpQbGFjZU5hbWU+IDxzdDE6UGxhY2VUeXBlIHc6c3Q9Im9uIj5UZXJy aXRvcnk8L3N0MTpQbGFjZVR5cGU+PC9zdDE6cGxhY2U+PG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCiAgPC90ZD4NCiA8L3RyPg0KPC90YWJsZT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 DQoxMi4wcHQnPkJ1dCBpdCBvbmx5IHRha2VzIHBhcnQgb2YgdGhlIHJhbmdlOiAmcXVvdDtUaGUg cHJpdmF0ZSB1c2UgY29kZXMgZnJvbQ0KWEEuLlhaIHdpbGwgbmV2ZXIgYmUgdXNlZCBieSBDTERS LCBhbmQgYXJlIHRodXMgc2FmZSBmb3IgdXNlIGZvciBvdGhlciBwdXJwb3Nlcw0KYnkgYXBwbGlj YXRpb25zIHVzaW5nIENMRFIgZGF0YSZxdW90Oy48YnI+DQo8YnI+DQpJdCB3b3VsZCBiZSBwb3Nz aWJsZSBmb3IgUkZDNDY0NmJpcyB0byBkZWZpbmUgYSByYW5nZSBvZiBwcml2YXRlIHVzZSBjb2Rl cyB0aGF0DQppdCB3aWxsIHVzZS4gVGhpcyB3b3VsZCBuZWVkIHRvIGJlIHZlcnkgY2FyZWZ1bGx5 IGRvbmUsIGFuZCB3ZSBtaWdodCBkZWNpZGUNCnRoYXQgaXQgaXMgbm90IGFwcHJvcHJpYXRlLCBi dXQgaXQgaXMgY2VydGFpbmx5IGEgcG9zc2liaWxpdHkuIDxicj4NCjxicj4NCk1hcms8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0K PC9odG1sPg0K ------_=_NextPart_001_01C6DAEA.751FE578-- --===============1290406673== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1290406673==-- From ltru-bounces@ietf.org Mon Sep 18 02:29:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPCdZ-0001GZ-OL; Mon, 18 Sep 2006 02:29:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPCdX-0001GQ-Ox for ltru@ietf.org; Mon, 18 Sep 2006 02:29:47 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPCdW-0000t5-G4 for ltru@ietf.org; Mon, 18 Sep 2006 02:29:47 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.628.4; Sun, 17 Sep 2006 23:29:45 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Sun, 17 Sep 2006 23:29:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: script tag for IPA Date: Sun, 17 Sep 2006 23:29:32 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: script tag for IPA Thread-Index: AcbaG/YnJ2tlWod8RiuVn4ldnbO/0gAzuTtg From: Peter Constable To: X-OriginalArrivalTime: 18 Sep 2006 06:29:45.0632 (UTC) FILETIME=[D53C8200:01C6DAEB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Jukka K. Korpela [mailto:jkorpela@cs.tut.fi] > > Just to clarify: IPA can be used to transcribe any language, but any > > instance of IPA transcription is in *some* particular language. >=20 > Normally so, but the particular language may be unknown; Even if it is unknown, it is still in some particular language. > this however is > no different from a case where you have, say, text in Latin letters = and > you do not know its language (yet).=20 Yes. ISO 639-2/-3 have "und" for that situation. > Moreover, it is possible to use IPA to > describe words that appear the same (in pronunciation) in different > languages, in which case we would probably use "mul" if we had to tag = the > text. I suppose one could use IPA notation to cite an abstracted utterance. = Abstracted usage -- i.e. independent of any language -- is often done = when discussing individual phonemes, but I don't know that I've ever = seen a single instance of a transcription of an abstracted utterance. But I'd suggest that, if a document contained such a thing, it would = make most sense either to leave it untagged, or to tag it "zxx" as it is = not content in any language, let alone multiple languages; it is just a = abstract phonetic sound. > So there are situations where there the language tagging is not > obvious, but this may happen for any script, not just IPA. Quite so; and again no tag or "zxx" makes more sense to me than "mul". Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 02:35:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPCiY-00035g-7A; Mon, 18 Sep 2006 02:34:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPCiW-00035b-Rh for ltru@lists.ietf.org; Mon, 18 Sep 2006 02:34:56 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPCiV-0001zn-DW for ltru@lists.ietf.org; Mon, 18 Sep 2006 02:34:56 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPCiM-0004mH-Na for ltru@lists.ietf.org; Mon, 18 Sep 2006 08:34:46 +0200 Received: from pd9fba907.dip0.t-ipconnect.de ([217.251.169.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 08:34:46 +0200 Received: from nobody by pd9fba907.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 08:34:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Sep 2006 08:31:48 +0200 Organization: Lines: 63 Message-ID: <450E3D54.39C1@xyzzy.claranet.de> References: <018701c6dab1$3ef889e0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba907.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [Ltru] Re: Process for creating 4646bis Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > I'm trying to gauge consensus myself, and we know how > dangerous it can be when individual members start doing that. That's editorial freedom, if we don't like the result we can disccuss it. [macrolanguage] > Again, there is no ticket and no consensus or hum declared by > the co-chairs. Yes, that's what I meant. > We'd better decide this pivotal question soon. For the initial draft stick to your choice, I only wanted to mention that it's still an open issue from my POV, it's also related to the new Preferred-Value / Deprecated rule. Do we go with 639-2 if possible, or stick to the extlang notation for a language once it's in, no matter what 639-2 says later ? >>> zh-min -> (no Preferred-Value, just deprecated) >> That has to be justified explicitly in prose, as an >> exception. > Does it? The Preferred-Values for the others are explicitly > listed to show how the tags were mapped. The judgment of the > WG is involved, although I think in these cases it will be > unassailable. In the case of "zh-min" the judgment of the WG > is that (a) the tag is deprecated because it doesn't refer to > a real language and (b) there is no Preferred-Value because > no alternative tagging possibility exists for this > non-language. Yes, and that has to be noted for readers of 4645bis, they've no clue how that happened, because it's not obviously triggered by the 639-3 input. [yi-latn] > Case is not significant in RFC { 1766, 3066, 4646, 4646bis } > language tags. There happen to be conventions for casing, > and the Registry uses those conventions, but they are not > normative. In another message I've quoted MUSTard, but admittedly that was about Script records, not directly for all script subtags elsewhere. It's just inconsistent, I stumbled over it with those XML IDs. The only script subtag not using titlecase, and the tag claims to be redundant, not irregular grandfathered garbage. > IMHO it would be more of an error if we "corrected" the case > of a previously registered tag; the whole point of keeping > redundant tags in the Registry is to preserve them in a > museum-like setting. The museum survives it if one yi-latn is fixed to yi-Latn. :-) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 02:47:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPCui-0007ql-8B; Mon, 18 Sep 2006 02:47:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPCug-0007qg-Sg for ltru@lists.ietf.org; Mon, 18 Sep 2006 02:47:30 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPCuf-000429-JB for ltru@lists.ietf.org; Mon, 18 Sep 2006 02:47:30 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPCuX-0006si-Gw for ltru@lists.ietf.org; Mon, 18 Sep 2006 08:47:21 +0200 Received: from pd9fba907.dip0.t-ipconnect.de ([217.251.169.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 08:47:21 +0200 Received: from nobody by pd9fba907.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 08:47:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Sep 2006 08:46:44 +0200 Organization: Lines: 9 Message-ID: <450E40D4.55C0@xyzzy.claranet.de> References: <30b660a20609161145h47e63289n1f9a96b9fc682c34@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba907.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Ltru] Re: ISO 15924 process X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > Just curious Same here, that's how I found the page Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 02:59:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPD5x-0003Xr-Ow; Mon, 18 Sep 2006 02:59:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPD5w-0003Xm-Ia for ltru@ietf.org; Mon, 18 Sep 2006 02:59:08 -0400 Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPD5s-00062L-1x for ltru@ietf.org; Mon, 18 Sep 2006 02:59:08 -0400 Received: from spam.cs.tut.fi (spam-eth1.lintula [10.11.18.2]) by mail.cs.tut.fi (Postfix) with ESMTP id 0204014E9 for ; Mon, 18 Sep 2006 09:58:57 +0300 (EEST) Received: from mail.cs.tut.fi ([130.230.4.42]) by spam.cs.tut.fi (spam.cs.tut.fi [10.11.18.2]) (amavisd-new, port 10024) with ESMTP id 23820-05 for ; Mon, 18 Sep 2006 09:58:56 +0300 (EEST) Received: from mustatilhi.cs.tut.fi (mustatilhi.cs.tut.fi [130.230.4.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id BABB9DBA for ; Mon, 18 Sep 2006 09:58:56 +0300 (EEST) Date: Mon, 18 Sep 2006 09:58:56 +0300 (EEST) From: "Jukka K. Korpela" To: ltru@ietf.org Subject: RE: [Ltru] Re: script tag for IPA In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: amavisd-new at cs.tut.fi X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sun, 17 Sep 2006, Peter Constable wrote: >> Moreover, it is possible to use IPA to >> describe words that appear the same (in pronunciation) in different >> languages, in which case we would probably use "mul" if we had to tag the >> text. > > I suppose one could use IPA notation to cite an abstracted utterance. > Abstracted usage -- i.e. independent of any language -- is often done > when discussing individual phonemes, but I don't know that I've ever > seen a single instance of a transcription of an abstracted utterance. Just to clarify: I did not mean an abstract utterance but something like "The word [kala] 'fish' has probably remained the same from the Uralian protolanguage to Finnish and Estonian but often changed considerably in other Uralian languages." (I'm cheating a bit here, in order to be able to use ASCII only, since [a] is not the most adequate vowel symbol here.) So it would not be an abstract utterance but a word that is allegedly the same in three languages, one of which is an uncertain reconstruction without a specific code. The same situation may, of course, also appear when words are written using some normal script instead of IPA. > But I'd suggest that, if a document contained such a thing, it would > make most sense either to leave it untagged, or to tag it "zxx" as it is > not content in any language, let alone multiple languages; it is just a > abstract phonetic sound. Perhaps. It depends on the context and requirements. I think the actual _utilization_ of language tagging in software is far behind the specification of codes for it, and it is therefore difficult to estimate the practical impact of tagging decisions in borderline cases. Most texts in the world have no language tagging, still less tagging at the level of individual words (or characters) even in cases where the tagging decision would be straightforward (e.g., in tagging personal names that clearly belong to a language other than the surrounding text). -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 03:17:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDNX-00019e-Gk; Mon, 18 Sep 2006 03:17:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDNU-00018N-61 for ltru@lists.ietf.org; Mon, 18 Sep 2006 03:17:16 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPDFv-0000MZ-GO for ltru@lists.ietf.org; Mon, 18 Sep 2006 03:09:28 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPDFk-0002Q1-15 for ltru@lists.ietf.org; Mon, 18 Sep 2006 09:09:16 +0200 Received: from pd9fba907.dip0.t-ipconnect.de ([217.251.169.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 09:09:16 +0200 Received: from nobody by pd9fba907.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 09:09:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Sep 2006 09:08:15 +0200 Organization: Lines: 16 Message-ID: <450E45DF.79AD@xyzzy.claranet.de> References: <01dc01c6dae6$cb0ae560$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba907.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] Re: zh-hakka X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > I'm not seeing the problem that Frank is seeing at all. For ALL prefixes, for ALL Suppress-Scripts, and for ALL Preferred-Values anywhere in the registry ALL subtags of the corresponding tags (or script subtags in the case of Suppress-Script) are registered. Minus one hakka in zh-hakka. What's so difficult about this ? Something that will never again happen under 4646 rules, a very special case. Line 117 in the registry to XML script, it had to be "hardwired". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 03:17:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDNU-00018v-Nc; Mon, 18 Sep 2006 03:17:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDNT-00017j-CT for ltru@ietf.org; Mon, 18 Sep 2006 03:17:15 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPDGb-0000ZU-TT for ltru@ietf.org; Mon, 18 Sep 2006 03:10:11 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Mon, 18 Sep 2006 00:10:09 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 00:10:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: script tag for IFrom ltru-bounces@ietf.org Mon Sep 18 03:17:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDNX-00019e-Gk; Mon, 18 Sep 2006 03:17:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDNU-00018N-61 for ltru@lists.ietf.org; Mon, 18 Sep 2006 03:17:16 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPDFv-0000MZ-GO for ltru@lists.ietf.org; Mon, 18 Sep 2006 03:09:28 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPDFk-0002Q1-15 for ltru@lists.ietf.org; Mon, 18 Sep 2006 09:09:16 +0200 Received: from pd9fba907.dip0.t-ipconnect.de ([217.251.169.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 09:09:16 +0200 Received: from nobody by pd9fba907.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 09:09:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Sep 2006 09:08:15 +0200 Organization: Lines: 16 Message-ID: <450E45DF.79AD@xyzzy.claranet.de> References: <01dc01c6dae6$cb0ae560$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba907.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] Re: zh-hakka X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > I'm not seeing the problem that Frank is seeing at all. For ALL prefixes, for ALL Suppress-Scripts, and for ALL Preferred-Values anywhere in the registry ALL subtags of the corresponding tags (or script subtags in the case of Suppress-Script) are registered. Minus one hakka in zh-hakka. What's so difficult about this ? Something that will never again happen under 4646 rules, a very special case. Line 117 in the registry to XML script, it had to be "hardwired". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 03:17:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDNU-00018v-Nc; Mon, 18 Sep 2006 03:17:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDNT-00017j-CT for ltru@ietf.org; Mon, 18 Sep 2006 03:17:15 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPDGb-0000ZU-TT for ltru@ietf.org; Mon, 18 Sep 2006 03:10:11 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.628.4; Mon, 18 Sep 2006 00:10:09 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 00:10:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: script tag for IPA Date: Mon, 18 Sep 2006 00:09:56 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: script tag for IPA Thread-Index: Acba7/qYrsgH8SF8Q7SSup13+hR0pgAAQYcQ From: Peter Constable To: X-OriginalArrivalTime: 18 Sep 2006 07:10:09.0417 (UTC) FILETIME=[79ECBF90:01C6DAF1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Jukka K. Korpela [mailto:jkorpela@cs.tut.fi] > Just to clarify: I did not mean an abstract utterance but something = like > "The word [kala] 'fish' has probably remained the same from the = Uralian > protolanguage to Finnish and Estonian but often changed considerably > in other Uralian languages." In that case, the transcription is of a reconstructed word form from = proto Uralic -- it's a word in a specific (reconstructed) language. Now, mind you, ISO 639 does *not* provide IDs for = historically-reconstructed proto-languages. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru PA Date: Mon, 18 Sep 2006 00:09:56 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: script tag for IPA Thread-Index: Acba7/qYrsgH8SF8Q7SSup13+hR0pgAAQYcQ From: Peter Constable To: X-OriginalArrivalTime: 18 Sep 2006 07:10:09.0417 (UTC) FILETIME=[79ECBF90:01C6DAF1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Jukka K. Korpela [mailto:jkorpela@cs.tut.fi] > Just to clarify: I did not mean an abstract utterance but something = like > "The word [kala] 'fish' has probably remained the same from the = Uralian > protolanguage to Finnish and Estonian but often changed considerably > in other Uralian languages." In that case, the transcription is of a reconstructed word form from = proto Uralic -- it's a word in a specific (reconstructed) language. Now, mind you, ISO 639 does *not* provide IDs for = historically-reconstructed proto-languages. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 03:17:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDNt-0001Lt-Bm; Mon, 18 Sep 2006 03:17:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDNs-0001LB-8D for ltru@ietf.org; Mon, 18 Sep 2006 03:17:40 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPDBa-0007SL-St for ltru@ietf.org; Mon, 18 Sep 2006 03:05:03 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.628.4; Mon, 18 Sep 2006 00:04:58 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 00:04:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: UTF-8 Date: Mon, 18 Sep 2006 00:04:42 -0700 Message-ID: In-Reply-To: <6.0.0.20.2.20060917165059.08a0ed10@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: UTF-8 Thread-Index: AcbawYelViphfL4URqC4QVY++5rsEQALPvLw From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 18 Sep 2006 07:04:58.0358 (UTC) FILETIME=[C084E960:01C6DAF0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Agreed. In my point of view, the pain of Bokm&#$!@*l outweights > a lot of things. The main benefit is that native people can > easily check that things are correct, which they won't do > if we show them just a number. There's lots of software that will interpret an NCR in an HTML, XML or = HTML file and display it to the user as the actual character in the UCS = for which it is a reference. I don't think there is any software that = will do this for the file located at = http://www.iana.org/assignments/language-subtag-registry.=20 Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 03:44:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDnp-00024Y-6e; Mon, 18 Sep 2006 03:44:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDno-00024T-Mi for ltru@lists.ietf.org; Mon, 18 Sep 2006 03:44:28 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPDnn-0000re-E7 for ltru@lists.ietf.org; Mon, 18 Sep 2006 03:44:28 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 9F6D526C110; Mon, 18 Sep 2006 09:44:10 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id B395B26C0E8; Mon, 18 Sep 2006 09:44:09 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id B0B0558ED24; Mon, 18 Sep 2006 09:44:09 +0200 (CEST) Date: Mon, 18 Sep 2006 09:44:09 +0200 From: Stephane Bortzmeyer To: Martin Duerst Message-ID: <20060918074409.GB16778@nic.fr> References: <6.0.0.20.2.20060918111628.08943ec0@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060918111628.08943ec0@localhost> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Frank Ellermann , ltru@lists.ietf.org Subject: [Ltru] [Partially OT] DOCTYPE ltru X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Mon, Sep 18, 2006 at 11:17:38AM +0900, Martin Duerst wrote a message of 127 lines which said: > As a co-chair, I marked this off-topic, unless I misunderstood you > to make this as a proposal for the actual registry. I do not think that Frank wanted XML to be the official format :-) Nevertheless, I find quite useful, even if it is officially OT, to discuss here about alternative formats (my proposal to host somewhere, in an unofficial site, the translations to other formats) or about implementations (such as Mark's regexp). Yes, it is not in the WG charter but tackling practical problems is also a good way to test the standard and to improve it. If the chairs insist :-) may be we could create a dedicated mailing list, "ltru-implementors" but I would regard this as useless duplication. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 03:46:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDpa-0002VK-PX; Mon, 18 Sep 2006 03:46:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDpZ-0002VB-Oe for ltru@lists.ietf.org; Mon, 18 Sep 2006 03:46:17 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPDpY-00018Y-Ey for ltru@lists.ietf.org; Mon, 18 Sep 2006 03:46:17 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 1616C26C11F; Mon, 18 Sep 2006 09:46:16 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 45A2C26C0E8; Mon, 18 Sep 2006 09:46:15 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 2AC4758ED24; Mon, 18 Sep 2006 09:46:15 +0200 (CEST) Date: Mon, 18 Sep 2006 09:46:15 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20060918074615.GC16778@nic.fr> References: <6.0.0.20.2.20060918111628.08943ec0@localhost> <450E263B.2B99@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450E263B.2B99@xyzzy.claranet.de> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@lists.ietf.org Subject: [Ltru] Re: [OT] DOCTYPE ltru X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Mon, Sep 18, 2006 at 06:53:15AM +0200, Frank Ellermann wrote a message of 50 lines which said: > > 'date' attributes should be changed to the more informative > > 'added'. > > For now I stick to date, because I use it for all registry dates, > not only Added fields, also for Deprecated and File-Date. I agree with Martin ( is better because it is what's in the RFC) but, since it is OT and unofficial, we'll just have two different XML schemas :-) If it would be a discussion on the RFC 4646bis standard format, we would try to reach a consensus, but if it is just testing, debugging and so on, there is no need to fight over the name of the XML elements :-) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 03:50:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDtC-00033l-Cx; Mon, 18 Sep 2006 03:50:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDtB-00033I-ED for ltru@ietf.org; Mon, 18 Sep 2006 03:50:01 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPDt9-0001em-Q6 for ltru@ietf.org; Mon, 18 Sep 2006 03:50:01 -0400 Received: by nf-out-0910.google.com with SMTP id n15so2995465nfc for ; Mon, 18 Sep 2006 00:49:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=CwmTlHss274TAOXFbmIJsx/8LyCc0D1eNaY9aJjPdt7WcdkrvT+PyUb3v066ZL0Frv2IP572gWFX52WzMFAbEZZPAVr5Ia/Zy+5+PiM16cm0rB/RtWoULex1CNsEGRiTPltp8iGyir+vREF7PT2kmnvKQlqOzz6u2u9JGZE5WIk= Received: by 10.48.48.15 with SMTP id v15mr16622984nfv; Mon, 18 Sep 2006 00:49:58 -0700 (PDT) Received: by 10.49.65.16 with HTTP; Mon, 18 Sep 2006 00:49:57 -0700 (PDT) Message-ID: <30b660a20609180049y42e87c75y43326807d071e7a7@mail.gmail.com> Date: Mon, 18 Sep 2006 00:49:58 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] ISO 15924 process In-Reply-To: MIME-Version: 1.0 References: <30b660a20609161145h47e63289n1f9a96b9fc682c34@mail.gmail.com> X-Google-Sender-Auth: 97247a483552a702 X-Spam-Score: 0.3 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1593674623==" Errors-To: ltru-bounces@ietf.org --===============1593674623== Content-Type: multipart/alternative; boundary="----=_Part_173403_12511191.1158565798047" ------=_Part_173403_12511191.1158565798047 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline VGhlIHBlb3BsZSBhcmUgaHR0cDovL3d3dy51bmljb2RlLm9yZy9pc28xNTkyNC9pc28xNTkyNGph Yy5odG1sClRoZSBwcm9jZXNzIGlzIGF0IGh0dHA6Ly93d3cudW5pY29kZS5vcmcvaXNvMTU5MjQv c3RhbmRhcmQvaW5kZXguaHRtbCNhbm5leAoKSSBoYXZlbid0IGxvb2tlZCBpdCBvdmVyIGF0IGFs bCwgbXlzZWxmLgoKTWFyawoKCgpPbiA5LzE3LzA2LCBQZXRlciBDb25zdGFibGUgPHBldGVyY29u QG1pY3Jvc29mdC5jb20+IHdyb3RlOgo+Cj4gIE1hcms6Cj4KPgo+Cj4gWW91IG1lbnRpb25lZCB5 b3Ugd2VyZSBhbiBvYnNlcnZlciB0byB0aGUgSVNPIDE1OTI0IHByb2Nlc3MuIENhbiB5b3UgZmls bAo+IHVzIGluIG9uIHRoYXQgcHJvY2Vzcz8KPgo+Cj4KPiAtICAgICAgICAgIENhbiB0aGUgcHVi bGljIG9ic2VydmUgdGhlIHByb2Nlc3MsIG9yIGFyZSB5b3UganVzdCBvbmUgb2YgdGhlCj4gZml2 ZSBub24tdm90aW5nIG9ic2VydmVycyBpbiBhbiBvdGhlcndpc2UgY2xvc2VkIHByb2Nlc3M/Cj4K PiAtICAgICAgICAgIFdobyBhcmUgdGhlIHJlcHMgZnJvbSBlYWNoIG9mIFRDNDYsIFRDMzcsIEpU QzEvU0MyIGFuZCB0aGUgUkE/Cj4KPgo+Cj4gSnVzdCBjdXJpb3Vz4oCmCj4KPgo+Cj4KPgo+IFBl dGVyCj4KPgo+ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPiAqRnJvbToqIE1h cmsgRGF2aXMgW21haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZ10KPiAqU2VudDoqIFNh dHVyZGF5LCBTZXB0ZW1iZXIgMTYsIDIwMDYgMTE6NDYgQU0KPiAqVG86KiBNYXJ0aW4gSG9za2Vu Cj4gKkNjOiogRG91ZyBFd2VsbDsgTFRSVSBXb3JraW5nIEdyb3VwCj4gKlN1YmplY3Q6KiBSZTog W0x0cnVdIFJlOiBzY3JpcHQgdGFnIGZvciBJUEEKPgo+Cj4KPiBJIGdlbmVyYWxseSBhZ3JlZSB3 aXRoIEFkZGlzb24ncyBjb21tZW50cy4gQSBjb3VwbGUgb2YgZnVydGhlciBpdGVtcy4KPgo+IDEu IFByb2NlZHVyYWxseSwgdGhlIHBvc3NpYmlsaXR5IG9mIGdldHRpbmcgYW4gSVBBIHNjcmlwdCB2 YXJpYW50IGlzIG5vdAo+IHplcm8uIEl0IHdhcyBwcm9wb3NlZCwgdGhlcmUgd2FzIHZlcnkgbGl0 dGxlIGRpc2N1c3Npb24sIGFuZCBkaXNtaXNzZWQKPiB3aXRob3V0IGEgbG90IG9mIGRpc2N1c3Np b24gKEknbSBqdXN0IGFuIG9ic2VydmVyKS4gU28gaWYgYSBtb3JlIHJlYXNvbmVkCj4gZG9jdW1l bnQgaXMgcHJlc2VudGVkIHRoZXJlIGNvdWxkIGJlIGRpZmZlcmVudCByZXN1bHRzLiBVbmxpa2Ug b3RoZXIgY2FzZXMsCj4gaXQgaXMgbm90IHVwIHRvIG9uZSBwZXJzb24gY2FwcmljaW91c25lc3Mu Cj4KPiAyLiBJIHRoaW5rIHRoZSBwcml2YXRlIHVzZSBjb2RlcyAoZm9yIHNjcmlwdCwgZXRjKSBh cmUgbWlzdW5kZXJzdG9vZC4gSWYKPiBhbiBhdXRob3JpdHkgZGVzaWduYXRlcyBhIGNvZGUgYXMg cHJpdmF0ZSB1c2UgY29kZSwgdGhhdCBtZWFucyB0aGF0IGl0IGlzCj4gcmVjb2duaXplZCBhcyBh IHZhbGlkIGNvZGUsIGJ1dCAqdGhhdCAqYXV0aG9yaXR5IGRvZXNuJ3QgYXR0YWNoIGEgbWVhbmlu Zwo+IHRvIGl0LCAqYW5kIG5ldmVyIHdpbGwuCj4KPiAqSXQgZG9lcyBub3QgbWVhbiB0aGF0IG5v Ym9keSBlbHNlIGNhbiBhdHRhY2ggYSBtZWFuaW5nIHRvIGl0IC0tIGlmIHRoYXQKPiB3ZXJlIHRo ZSBjYXNlIGl0IHdvdWxkIGJlIGNvbXBsZXRlbHkgcG9pbnRsZXNzIHRvIGhhdmUgcHJpdmF0ZSB1 c2UgY29kZXMuCj4gRm9yIGV4YW1wbGUsIHRoZSBVbmljb2RlIENvbnNvcnRpdW0gZGVmaW5lcyBh IG1lYW5pbmcgZm9yIFFhYWkgKAo+IGh0dHA6Ly93d3cudW5pY29kZS5vcmcvcmVwb3J0cy90cjI0 LykuIEFueSBhcHBsaWNhdGlvbiBjb25mb3JtYW50IHRvIHRoZQo+IFVuaWNvZGUgU3RhbmRhcmQg bXVzdCBpbnRlcnByZXQgUWFhaSBhcyBhcHBsaWVkIHdpdGggdGhhdCBtZWFuaW5nLiBJdCBhbHNv Cj4gYXR0YWNoZXMgbWVhbmluZyB0byBjZXJ0YWluIHByaXZhdGUgdXNlIHRhZ3MgaW4gQ0xEUiAo TERNTCksIG5vdGFibHkgZm9yCj4gc29tZSByZWdpb24gY29kZXM6Cj4KPiBRTwo+Cj4gT3V0bHlp bmcgT2NlYW5pYQo+Cj4gUVUKPgo+IEV1cm9wZWFuIFVuaW9uCj4KPiBaWgo+Cj4gVW5rbm93biBv ciBJbnZhbGlkIFRlcnJpdG9yeQo+Cj4gQnV0IGl0IG9ubHkgdGFrZXMgcGFydCBvZiB0aGUgcmFu Z2U6ICJUaGUgcHJpdmF0ZSB1c2UgY29kZXMgZnJvbSBYQS4uWFoKPiB3aWxsIG5ldmVyIGJlIHVz ZWQgYnkgQ0xEUiwgYW5kIGFyZSB0aHVzIHNhZmUgZm9yIHVzZSBmb3Igb3RoZXIgcHVycG9zZXMg YnkKPiBhcHBsaWNhdGlvbnMgdXNpbmcgQ0xEUiBkYXRhIi4KPgo+IEl0IHdvdWxkIGJlIHBvc3Np YmxlIGZvciBSRkM0NjQ2YmlzIHRvIGRlZmluZSBhIHJhbmdlIG9mIHByaXZhdGUgdXNlIGNvZGVz Cj4gdGhhdCBpdCB3aWxsIHVzZS4gVGhpcyB3b3VsZCBuZWVkIHRvIGJlIHZlcnkgY2FyZWZ1bGx5 IGRvbmUsIGFuZCB3ZSBtaWdodAo+IGRlY2lkZSB0aGF0IGl0IGlzIG5vdCBhcHByb3ByaWF0ZSwg YnV0IGl0IGlzIGNlcnRhaW5seSBhIHBvc3NpYmlsaXR5Lgo+Cj4gTWFyawo+Cj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBMdHJ1IG1haWxpbmcgbGlz dAo+IEx0cnVAaWV0Zi5vcmcKPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9sdHJ1Cj4KPgo+Cg== ------=_Part_173403_12511191.1158565798047 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VGhlIHBlb3BsZSBhcmUgPGEgaHJlZj0iaHR0cDovL3d3dy51bmljb2RlLm9yZy9pc28xNTkyNC9p c28xNTkyNGphYy5odG1sIj5odHRwOi8vd3d3LnVuaWNvZGUub3JnL2lzbzE1OTI0L2lzbzE1OTI0 amFjLmh0bWw8L2E+PGJyPlRoZSBwcm9jZXNzIGlzIGF0IDxhIGhyZWY9Imh0dHA6Ly93d3cudW5p Y29kZS5vcmcvaXNvMTU5MjQvc3RhbmRhcmQvaW5kZXguaHRtbCNhbm5leCI+aHR0cDovL3d3dy51 bmljb2RlLm9yZy9pc28xNTkyNC9zdGFuZGFyZC9pbmRleC5odG1sI2FubmV4CjwvYT48YnI+PGJy PkkgaGF2ZW4ndCBsb29rZWQgaXQgb3ZlciBhdCBhbGwsIG15c2VsZi48YnI+PGJyPk1hcms8YnI+ PGJyPjxicj48YnI+PGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDkvMTcvMDYsIDxi IGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5QZXRlciBDb25zdGFibGU8L2I+ICZsdDs8YSBocmVm PSJtYWlsdG86cGV0ZXJjb25AbWljcm9zb2Z0LmNvbSI+cGV0ZXJjb25AbWljcm9zb2Z0LmNvbQo8 L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0 IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+PGRpdj4KCgoKCgoKCgoKCgoKPGRp diBsaW5rPSJibHVlIiB2bGluaz0iYmx1ZSIgbGFuZz0iRU4tVVMiPgoKPGRpdj4KCjxwPjxmb250 IGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogbmF2eTsiPk1hcms6PC9zcGFuPjwv Zm9udD48L3A+Cgo8cD48Zm9udCBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IG5h dnk7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250IGNvbG9yPSJuYXZ5IiBmYWNl PSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1p bHk6IEFyaWFsOyBjb2xvcjogbmF2eTsiPllvdSBtZW50aW9uZWQgeW91IHdlcmUgYW4gb2JzZXJ2 ZXIgdG8gdGhlCklTTyAxNTkyNCBwcm9jZXNzLiBDYW4geW91IGZpbGwgdXMgaW4gb24gdGhhdCBw cm9jZXNzPzwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgY29sb3I9Im5hdnkiIGZhY2U9IkFy aWFsIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog QXJpYWw7IGNvbG9yOiBuYXZ5OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+Cgo8cCBzdHlsZT0i bWFyZ2luLWxlZnQ6IDAuNWluOyB0ZXh0LWluZGVudDogLTAuMjVpbjsiPjxmb250IGNvbG9yPSJu YXZ5IiBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsg Zm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogbmF2eTsiPjxzcGFuPi08Zm9udCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIHNpemU9IjEiPjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9m b250PjxzcGFuIGRpcj0ibHRyIj48Zm9udCBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiIHNpemU9 IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29s b3I6IG5hdnk7Ij5DYW4gdGhlIHB1YmxpYyBvYnNlcnZlIHRoZSBwcm9jZXNzLCBvciBhcmUgeW91 IGp1c3Qgb25lIG9mIHRoZSBmaXZlCm5vbi12b3Rpbmcgb2JzZXJ2ZXJzIGluIGFuIG90aGVyd2lz ZSBjbG9zZWQgcHJvY2Vzcz88L3NwYW4+PC9mb250Pjwvc3Bhbj48L3A+Cgo8cCBzdHlsZT0ibWFy Z2luLWxlZnQ6IDAuNWluOyB0ZXh0LWluZGVudDogLTAuMjVpbjsiPjxmb250IGNvbG9yPSJuYXZ5 IiBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9u dC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogbmF2eTsiPjxzcGFuPi08Zm9udCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iIHNpemU9IjEiPjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250 PjxzcGFuIGRpcj0ibHRyIj48Zm9udCBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6 IG5hdnk7Ij5XaG8gYXJlIHRoZSByZXBzIGZyb20gZWFjaCBvZiBUQzQ2LCBUQzM3LCBKVEMxL1ND MiBhbmQgdGhlIFJBPzwvc3Bhbj4KPC9mb250Pjwvc3Bhbj48L3A+Cgo8cD48Zm9udCBjb2xvcj0i bmF2eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IG5hdnk7Ij4mbmJzcDs8L3NwYW4+PC9mb250Pjwv cD4KCjxwPjxmb250IGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogbmF2eTsiPkp1 c3QgY3VyaW91c+KApjwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgY29sb3I9Im5hdnkiIGZh Y2U9IkFyaWFsIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZh bWlseTogQXJpYWw7IGNvbG9yOiBuYXZ5OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+Cgo8cD48 Zm9udCBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IG5hdnk7Ij4mbmJzcDs8L3Nw YW4+PC9mb250PjwvcD4KCjxwPjxmb250IGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCIgc2l6ZT0i MiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xv cjogbmF2eTsiPlBldGVyPC9zcGFuPjwvZm9udD48L3A+Cgo8cD48Zm9udCBjb2xvcj0ibmF2eSIg ZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQt ZmFtaWx5OiBBcmlhbDsgY29sb3I6IG5hdnk7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxk aXYgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1jb2xv cjogLW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQt Y29sb3IgYmx1ZTsgYm9yZGVyLXdpZHRoOiBtZWRpdW0gbWVkaXVtIG1lZGl1bSAxLjVwdDsgcGFk ZGluZzogMGluIDBpbiAwaW4gNHB0OyI+Cgo8ZGl2PgoKPGRpdiBzdHlsZT0idGV4dC1hbGlnbjog Y2VudGVyOyIgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXpl PSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyI+Cgo8aHIgYWxpZ249ImNlbnRlciIg c2l6ZT0iMiIgd2lkdGg9IjEwMCUiPgoKPC9zcGFuPjwvZm9udD48L2Rpdj4KCjxwPjxiPjxmb250 IGZhY2U9IlRhaG9tYSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9u dC1mYW1pbHk6IFRhaG9tYTsgZm9udC13ZWlnaHQ6IGJvbGQ7Ij5Gcm9tOjwvc3Bhbj48L2ZvbnQ+ PC9iPjxmb250IGZhY2U9IlRhaG9tYSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYTsiPiBNYXJrIERhdmlzClttYWlsdG86PGEgaHJlZj0i bWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnIiB0YXJnZXQ9Il9ibGFuayIgb25jbGlj az0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPm1hcmsuZGF2 aXNAaWN1LXByb2plY3Qub3JnPC9hPl0gPGJyPgo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 IGJvbGQ7Ij5TZW50Ojwvc3Bhbj48L2I+IFNhdHVyZGF5LCBTZXB0ZW1iZXIgMTYsIDIwMDYKMTE6 NDYgQU08YnI+CjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsiPlRvOjwvc3Bhbj48 L2I+IE1hcnRpbiBIb3NrZW48YnI+CjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsi PkNjOjwvc3Bhbj48L2I+IERvdWcgRXdlbGw7IExUUlUgV29ya2luZyBHcm91cDxicj4KPGI+PHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogW0x0 cnVdIFJlOiBzY3JpcHQgdGFnCmZvciBJUEE8L3NwYW4+PC9mb250PjwvcD4KCjwvZGl2PgoKPHA+ PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMnB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+Cgo8cD48Zm9udCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij5JIGdl bmVyYWxseSBhZ3JlZSB3aXRoIEFkZGlzb24ncwpjb21tZW50cy4gQSBjb3VwbGUgb2YgZnVydGhl ciBpdGVtcy48YnI+Cjxicj4KMS4gUHJvY2VkdXJhbGx5LCB0aGUgcG9zc2liaWxpdHkgb2YgZ2V0 dGluZyBhbiBJUEEgc2NyaXB0IHZhcmlhbnQgaXMgbm90IHplcm8uCkl0IHdhcyBwcm9wb3NlZCwg dGhlcmUgd2FzIHZlcnkgbGl0dGxlIGRpc2N1c3Npb24sIGFuZCBkaXNtaXNzZWQgd2l0aG91dCBh IGxvdApvZiBkaXNjdXNzaW9uIChJJ20ganVzdCBhbiBvYnNlcnZlcikuIFNvIGlmIGEgbW9yZSBy ZWFzb25lZCBkb2N1bWVudCBpcwpwcmVzZW50ZWQgdGhlcmUgY291bGQgYmUgZGlmZmVyZW50IHJl c3VsdHMuIFVubGlrZSBvdGhlciBjYXNlcywgaXQgaXMgbm90IHVwIHRvCm9uZSBwZXJzb24gY2Fw cmljaW91c25lc3MuIDxicj4KPGJyPgoyLiBJIHRoaW5rIHRoZSBwcml2YXRlIHVzZSBjb2RlcyAo Zm9yIHNjcmlwdCwgZXRjKSBhcmUgbWlzdW5kZXJzdG9vZC4gSWYgYW4KYXV0aG9yaXR5IGRlc2ln bmF0ZXMgYSBjb2RlIGFzIHByaXZhdGUgdXNlIGNvZGUsIHRoYXQgbWVhbnMgdGhhdCBpdCBpcwpy ZWNvZ25pemVkIGFzIGEgdmFsaWQgY29kZSwgYnV0IDxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDogYm9sZDsgZm9udC1zdHlsZTogaXRhbGljOyI+dGhhdCA8L3NwYW4+PC9pPjwvYj5hdXRo b3JpdHkgZG9lc24ndCBhdHRhY2ggYSBtZWFuaW5nIHRvIGl0LCA8aT48c3BhbiBzdHlsZT0iZm9u dC1zdHlsZTogaXRhbGljOyI+YW5kIG5ldmVyIHdpbGwuPGJyPgo8YnI+Cjwvc3Bhbj48L2k+SXQg ZG9lcyBub3QgbWVhbiB0aGF0IG5vYm9keSBlbHNlIGNhbiBhdHRhY2ggYSBtZWFuaW5nIHRvIGl0 IC0tIGlmCnRoYXQgd2VyZSB0aGUgY2FzZSBpdCB3b3VsZCBiZSBjb21wbGV0ZWx5IHBvaW50bGVz cyB0byBoYXZlIHByaXZhdGUgdXNlIGNvZGVzLgpGb3IgZXhhbXBsZSwgdGhlIFVuaWNvZGUgQ29u c29ydGl1bSBkZWZpbmVzIGEgbWVhbmluZyBmb3IgUWFhaSAoIDxhIGhyZWY9Imh0dHA6Ly93d3cu dW5pY29kZS5vcmcvcmVwb3J0cy90cjI0LyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVy biB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5odHRwOi8vd3d3LnVuaWNv ZGUub3JnL3JlcG9ydHMvdHIyNC88L2E+CikuCkFueSBhcHBsaWNhdGlvbiBjb25mb3JtYW50IHRv IHRoZSBVbmljb2RlIFN0YW5kYXJkIG11c3QgaW50ZXJwcmV0IFFhYWkgYXMKYXBwbGllZCB3aXRo IHRoYXQgbWVhbmluZy4gSXQgYWxzbyBhdHRhY2hlcyBtZWFuaW5nIHRvIGNlcnRhaW4gcHJpdmF0 ZSB1c2UgdGFncwppbiBDTERSIChMRE1MKSwgbm90YWJseSBmb3Igc29tZSByZWdpb24gY29kZXM6 IDwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHRhYmxlIHN0eWxlPSJtYXJnaW4tbGVmdDogNnB0OyIgYm9y ZGVyPSIxIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPgogPHRib2R5Pjx0cj4KICA8 dGQgc3R5bGU9InBhZGRpbmc6IDEuNXB0OyI+CiAgPHAgc3R5bGU9Im1hcmdpbi1yaWdodDogMGlu OyBtYXJnaW4tYm90dG9tOiA2cHQ7IG1hcmdpbi1sZWZ0OiAwaW47Ij48Zm9udCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij5RTzwv c3Bhbj48L2ZvbnQ+PC9wPgogIDwvdGQ+CiAgPHRkIHN0eWxlPSJwYWRkaW5nOiAxLjVwdDsiPgog IDxwIHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogNnB0OyBtYXJnaW4t bGVmdDogMGluOyI+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMnB0OyI+T3V0bHlpbmcgT2NlYW5pYTwvc3Bhbj48L2ZvbnQ+PC9w PgogIDwvdGQ+CiA8L3RyPgogPHRyPgogIDx0ZCBzdHlsZT0icGFkZGluZzogMS41cHQ7Ij4KICA8 cCBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDZwdDsgbWFyZ2luLWxl ZnQ6IDBpbjsiPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTJwdDsiPlFVPC9zcGFuPjwvZm9udD48L3A+CiAgPC90ZD4KICA8dGQg c3R5bGU9InBhZGRpbmc6IDEuNXB0OyI+CiAgPHAgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBt YXJnaW4tYm90dG9tOiA2cHQ7IG1hcmdpbi1sZWZ0OiAwaW47Ij48Zm9udCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij5FdXJvcGVh biBVbmlvbjwvc3Bhbj48L2ZvbnQ+PC9wPgogIDwvdGQ+CiA8L3RyPgogPHRyPgogIDx0ZCBzdHls ZT0icGFkZGluZzogMS41cHQ7Ij4KICA8cCBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdp bi1ib3R0b206IDZwdDsgbWFyZ2luLWxlZnQ6IDBpbjsiPjxmb250IGZhY2U9IlRpbWVzIE5ldyBS b21hbiIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiPlpaPC9zcGFuPjwv Zm9udD48L3A+CiAgPC90ZD4KICA8dGQgc3R5bGU9InBhZGRpbmc6IDEuNXB0OyI+CiAgPHAgc3R5 bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9tOiA2cHQ7IG1hcmdpbi1sZWZ0OiAw aW47Ij48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEycHQ7Ij5Vbmtub3duIG9yIEludmFsaWQgVGVycml0b3J5PC9zcGFuPjwvZm9u dD48L3A+CiAgPC90ZD4KIDwvdHI+CjwvdGJvZHk+PC90YWJsZT4KCjxwPjxmb250IGZhY2U9IlRp bWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiPkJ1 dCBpdCBvbmx5IHRha2VzIHBhcnQgb2YgdGhlIHJhbmdlOiAmcXVvdDtUaGUgcHJpdmF0ZSB1c2Ug Y29kZXMgZnJvbQpYQS4uWFogd2lsbCBuZXZlciBiZSB1c2VkIGJ5IENMRFIsIGFuZCBhcmUgdGh1 cyBzYWZlIGZvciB1c2UgZm9yIG90aGVyIHB1cnBvc2VzCmJ5IGFwcGxpY2F0aW9ucyB1c2luZyBD TERSIGRhdGEmcXVvdDsuPGJyPgo8YnI+Ckl0IHdvdWxkIGJlIHBvc3NpYmxlIGZvciBSRkM0NjQ2 YmlzIHRvIGRlZmluZSBhIHJhbmdlIG9mIHByaXZhdGUgdXNlIGNvZGVzIHRoYXQKaXQgd2lsbCB1 c2UuIFRoaXMgd291bGQgbmVlZCB0byBiZSB2ZXJ5IGNhcmVmdWxseSBkb25lLCBhbmQgd2UgbWln aHQgZGVjaWRlCnRoYXQgaXQgaXMgbm90IGFwcHJvcHJpYXRlLCBidXQgaXQgaXMgY2VydGFpbmx5 IGEgcG9zc2liaWxpdHkuIDxicj4KPGJyPgpNYXJrPC9zcGFuPjwvZm9udD48L3A+Cgo8L2Rpdj4K CjwvZGl2PgoKPC9kaXY+CgoKPC9kaXY+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPkx0cnUgbWFpbGluZyBsaXN0PGJyPjxhIG9uY2xpY2s9InJl dHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86 THRydUBpZXRmLm9yZyI+THRydUBpZXRmLm9yZzwvYT48YnI+PGEgb25jbGljaz0icmV0dXJuIHRv cC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Imh0dHBzOi8vd3d3MS5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUiIHRhcmdldD0iX2JsYW5rIj4KaHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydTwvYT48YnI+PGJyPjxicj48L2Jsb2Nr cXVvdGU+PC9kaXY+PGJyPgo= ------=_Part_173403_12511191.1158565798047-- --===============1593674623== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1593674623==-- From ltru-bounces@ietf.org Mon Sep 18 04:52:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPEs0-0003DA-F8; Mon, 18 Sep 2006 04:52:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPErz-0003D5-9O for ltru@lists.ietf.org; Mon, 18 Sep 2006 04:52:51 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPErw-0007fN-SZ for ltru@lists.ietf.org; Mon, 18 Sep 2006 04:52:51 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPErl-0000ZC-AL for ltru@lists.ietf.org; Mon, 18 Sep 2006 10:52:37 +0200 Received: from pd9fba92e.dip0.t-ipconnect.de ([217.251.169.46]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 10:52:37 +0200 Received: from nobody by pd9fba92e.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 10:52:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Sep 2006 10:51:17 +0200 Organization: Lines: 19 Message-ID: <450E5E05.1947@xyzzy.claranet.de> References: <6.0.0.20.2.20060918111628.08943ec0@localhost> <450E263B.2B99@xyzzy.claranet.de> <20060918074615.GC16778@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba92e.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: [OT] DOCTYPE ltru X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > no need to fight over the name of the XML elements :-) Yes, maybe different philosophies, in XHTML I don't like the many names for what's in essence an URL, src=, href=, cite=, codebase=, maybe more. Maybe the new W3C Unicorn validator will support RELAX (?) Less than 40 hours after writing a first DTD I'm not ready to throw it away. After all it does something useful, now all here can check cross-references in registries with gawk and the online validator. With almost 640 KB the 4645bis registry is a bit too large for manual plausibility checks. Frank P.S.: I really proposed CharMapML for a new charset registry _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 09:32:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPJDt-00007J-39; Mon, 18 Sep 2006 09:31:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPJDs-000079-3N for ltru@ietf.org; Mon, 18 Sep 2006 09:31:44 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPJDq-0001rj-Rz for ltru@ietf.org; Mon, 18 Sep 2006 09:31:44 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060918133142.DWCN27224.mta10.adelphia.net@DGBP7M81>; Mon, 18 Sep 2006 09:31:42 -0400 Message-ID: <021301c6db26$c7d568d0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <01dc01c6dae6$cb0ae560$6401a8c0@DGBP7M81> <450E45DF.79AD@xyzzy.claranet.de> <20060918103449.GB9546@nic.fr> Date: Mon, 18 Sep 2006 06:31:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Frank Ellermann Subject: [Ltru] Re: zh-hakka X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > On Mon, Sep 18, 2006 at 09:08:15AM +0200, > Frank Ellermann wrote > a message of 16 lines which said: > >> For ALL prefixes, for ALL Suppress-Scripts, and for ALL >> Preferred-Values anywhere in the registry ALL subtags of the >> corresponding tags (or script subtags in the case of >> Suppress-Script) are registered. > > Yes, but it is a consequence of RFC 4646 rules or is it just a > coincidence? It's just a coincidence. There is no restriction that a Preferred-Value cannot be a grandfathered tag. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 09:56:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPJbV-0001Eg-GK; Mon, 18 Sep 2006 09:56:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPJbT-0001EZ-Bv for ltru@ietf.org; Mon, 18 Sep 2006 09:56:07 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPJbR-0001nb-2N for ltru@ietf.org; Mon, 18 Sep 2006 09:56:07 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060918135600.FVDM27224.mta10.adelphia.net@DGBP7M81> for ; Mon, 18 Sep 2006 09:56:00 -0400 Message-ID: <021501c6db2a$2cf8cc90$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 18 Sep 2006 06:56:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Ltru] Re: Process for creating 4646bis Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> The Preferred-Values for the others are explicitly listed to show how >> the tags were mapped. The judgment of the WG is involved, although I >> think in these cases it will be unassailable. In the case of >> "zh-min" the judgment of the WG is that (a) the tag is deprecated >> because it doesn't refer to a real language and (b) there is no >> Preferred-Value because no alternative tagging possibility exists for >> this non-language. > > Yes, and that has to be noted for readers of 4645bis, they've no clue > how that happened, because it's not obviously triggered by the 639-3 > input. OK, I will add this. > [yi-latn] >> Case is not significant in RFC { 1766, 3066, 4646, 4646bis } language >> tags. There happen to be conventions for casing, and the Registry >> uses those conventions, but they are not normative. > > In another message I've quoted MUSTard, but admittedly that was about > Script records, not directly for all script subtags elsewhere. I found the passage in RFC 4646 to which you might have been referring, in Section 3.1 (which I swear is longer by itself than some RFCs): "The 'Subtag' or 'Tag' field MUST use lowercase letters to form the subtag or tag, with two exceptions. Subtags whose 'Type' field is 'script' (in other words, subtags defined by ISO 15924) MUST use titlecase. Subtags whose 'Type' field is 'region' (in other words, subtags defined by ISO 3166) MUST use uppercase. These exceptions mirror the use of case in the underlying standards." This actually says that all "Tag" fields in the Registry, meaning grandfathered and redundant tags, must be all-lowercase. Since grandfathered and redundant tags are atomic, and not composed of subtags (though redundant tags are equivalent to a sequence of valid subtags), this means "yi-latn" is one of the few redundant tags to be cased correctly! Seriously, I think this passage is in error with respect to "tags" and needs to be modified to say that redundant tags are either: (a) cased as they were in the RFC 3066 registry (what I did), or (b) cased as if they were composed of individual subtags, using the casing conventions for those subtags (what you want). > The museum survives it if one yi-latn is fixed to yi-Latn. :-) s/The museum survives it/The floodgates open/ But if the wording in Section 3.1 is changed to option (b) above, I'll be happy to make this change for you. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 10:20:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPJyg-0001qt-4H; Mon, 18 Sep 2006 10:20:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPJyf-0001pu-5t for ltru@ietf.org; Mon, 18 Sep 2006 10:20:05 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPJyd-0007w7-TX for ltru@ietf.org; Mon, 18 Sep 2006 10:20:05 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 4F7F926C191; Mon, 18 Sep 2006 16:19:53 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 2A70126C12A; Mon, 18 Sep 2006 16:19:52 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 1E00058EBBD; Mon, 18 Sep 2006 16:19:52 +0200 (CEST) Date: Mon, 18 Sep 2006 16:19:52 +0200 From: Stephane Bortzmeyer To: Addison Phillips Message-ID: <20060918141952.GA24227@nic.fr> References: <450C4DAB.4040102@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450C4DAB.4040102@yahoo-inc.com> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: 'LTRU Working Group' Subject: [Ltru] Re: [OT] record-jar format draft... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sat, Sep 16, 2006 at 12:16:59PM -0700, Addison Phillips wrote a message of 28 lines which said: > Today I updated my draft-00 of it and posted it on my personal web site. Wouldn't it a good idea to mention the related stuff such as JSON (RFC 4627) or XML (Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0", W3C REC-xml-1998, February 1998, .). Because, when reading the draft, the innocent beginner may wonder: "Why yet another format?" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 10:55:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPKWz-00057o-Mk; Mon, 18 Sep 2006 10:55:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPKWx-00057C-Ml for ltru@ietf.org; Mon, 18 Sep 2006 10:55:31 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPKWq-0000i3-UZ for ltru@ietf.org; Mon, 18 Sep 2006 10:55:31 -0400 Received: from [10.72.76.233] (snvvpn2-10-72-76-c233.corp.yahoo.com [10.72.76.233]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8IEtLMu039178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Sep 2006 07:55:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=QTYjRW6dups+qnq79mLHU2pKXVgacdg6Nh28odL/vW7C+a7u24++Awyx/9ki603G Message-ID: <450EB359.3090006@yahoo-inc.com> Date: Mon, 18 Sep 2006 07:55:21 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] RFC 4646 production "grandfathered" considered harmful References: <20060917061912.GB26073@ccil.org> <450D81D7.1070004@yahoo-inc.com> <30b660a20609171508s36585ea5r2311f0ac4c3cb2fe@mail.gmail.com> <6.0.0.20.2.20060918120033.07504ab0@localhost> In-Reply-To: <6.0.0.20.2.20060918120033.07504ab0@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > [chair hat on] > I have seen at least four people approving the idea to list > grandfathered/irregular tags explicitly, and nobody opposed. > I think that in principle, we seem to have consensus to go this > way, although some details may need to be worked out (see below). > If anybody disagrees with this assessment, please state so soon. > [editor hat on] I'll prepare an updated ABNF shortly. > > [chair hat off] > I clearly thing that it is a bad idea to include somebody's name > in a nonterminal of an ABNF. This is true both in general and also > in this specific case. When Michael proposed and approved the > tags listed below, they were not in any way illegal or irregular. [contributor hat on] I agree. I think that proposal was made tongue-in-cheek. I intend to start with the production "irregular" shown below Addison >> >> >> grandfathered = irregular >> >> / 1*3ALPHA 1*2("-" (2*8alphanum)) ; registered grandfathered codes that are well-formed, but would not otherwise be valid >> >> 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" >> -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 11:45:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPLJD-0004PY-Jl; Mon, 18 Sep 2006 11:45:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPLJC-0004PT-9B for ltru@ietf.org; Mon, 18 Sep 2006 11:45:22 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPLJ9-0000HK-Ib for ltru@ietf.org; Mon, 18 Sep 2006 11:45:22 -0400 Received: from [10.72.76.233] (snvvpn2-10-72-76-c233.corp.yahoo.com [10.72.76.233]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8IFj7V9041089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Sep 2006 08:45:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=iG7RDUNjzz+lXKGE9CnagYB5p+WOzbmD+QxrmBCIebUOGS9+CUFhFxyQ7tZEAq81 Message-ID: <450EBF03.7000905@yahoo-inc.com> Date: Mon, 18 Sep 2006 08:45:07 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <450C4DAB.4040102@yahoo-inc.com> <20060918141952.GA24227@nic.fr> In-Reply-To: <20060918141952.GA24227@nic.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: record-jar@yahoogroups.com, 'LTRU Working Group' Subject: [Ltru] Re: [OT] record-jar format draft... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > On Sat, Sep 16, 2006 at 12:16:59PM -0700, > Addison Phillips wrote > a message of 28 lines which said: > >> Today I updated my draft-00 of it and posted it on my personal web site. > > Wouldn't it a good idea to mention the related stuff such as JSON (RFC > 4627) or XML (Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible > Markup Language (XML) 1.0", W3C REC-xml-1998, February 1998, > .). > > Because, when reading the draft, the innocent beginner may wonder: > "Why yet another format?" Thanks for the comment. I'm not sure that referencing other formats explicitly is necessary (where does one stop?!?), but the Introduction could be a bit more expansive. Addison PS> I'd prefer not to discuss that draft here, unless LTRU decides that it would be better to remove the record-jar descriptive material and reference my I-D. I'd prefer not to add a dependency, if at all possible. -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 14:56:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPOHm-0005hV-Ad; Mon, 18 Sep 2006 14:56:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPOHl-0005hQ-Fr for ltru@ietf.org; Mon, 18 Sep 2006 14:56:05 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPOHk-0007sw-52 for ltru@ietf.org; Mon, 18 Sep 2006 14:56:05 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8IItnXd047354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Sep 2006 11:55:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=b14wGgyzYV5WHeYehmf3TS5RzU0xmtna/8reQTtvL1CjkULFxOcgF+nyzphS7Okn Message-ID: <450EEBB4.8000902@yahoo-inc.com> Date: Mon, 18 Sep 2006 11:55:48 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Process for creating 4646bis Registry References: <021501c6db2a$2cf8cc90$6401a8c0@DGBP7M81> In-Reply-To: <021501c6db2a$2cf8cc90$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > Seriously, I think this passage is in error with respect to "tags" and > needs to be modified to say that redundant tags are either: > > (a) cased as they were in the RFC 3066 registry (what I did), or > (b) cased as if they were composed of individual subtags, using the > casing conventions for those subtags (what you want). > >> The museum survives it if one yi-latn is fixed to yi-Latn. :-) > > s/The museum survives it/The floodgates open/ > > But if the wording in Section 3.1 is changed to option (b) above, I'll > be happy to make this change for you. > Section 3.1 will be changed to reflect (b), as I believe this was an oversight. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 15:08:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPOTP-0003bv-J0; Mon, 18 Sep 2006 15:08:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPOTN-0003bD-BY for ltru@ietf.org; Mon, 18 Sep 2006 15:08:05 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPOTL-0001vS-W9 for ltru@ietf.org; Mon, 18 Sep 2006 15:08:05 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8IJ7jo3047933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Sep 2006 12:07:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=Mw1S/un7yUO9MGJvfDt0l4tcuwqA7ttf7gOUuSpXty5SaPb0h1bf/xjkmBxTvFDp Message-ID: <450EEE81.70603@yahoo-inc.com> Date: Mon, 18 Sep 2006 12:07:45 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: zh-hakka References: <01dc01c6dae6$cb0ae560$6401a8c0@DGBP7M81> <450E45DF.79AD@xyzzy.claranet.de> <20060918103449.GB9546@nic.fr> <021301c6db26$c7d568d0$6401a8c0@DGBP7M81> In-Reply-To: <021301c6db26$c7d568d0$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Frank Ellermann , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Stephane Bortzmeyer wrote: > >> On Mon, Sep 18, 2006 at 09:08:15AM +0200, >> Frank Ellermann wrote >> a message of 16 lines which said: >> >>> For ALL prefixes, for ALL Suppress-Scripts, and for ALL >>> Preferred-Values anywhere in the registry ALL subtags of the >>> corresponding tags (or script subtags in the case of >>> Suppress-Script) are registered. >> >> Yes, but it is a consequence of RFC 4646 rules or is it just a >> coincidence? > > It's just a coincidence. There is no restriction that a Preferred-Value > cannot be a grandfathered tag. > It's a coincidence, but one that is desirable. In other words, I think it would be a Bad Thing to deprecate some value in favor of a grandfathered tag in the post-RFC 4646 era. In fact, the rules explicitly allow a Preferred-Value to be a tag, if the thing being deprecated is a grandfathered item. In 4646bis, for example, it says: -- # For fields of type 'script', 'region', and 'variant', 'Preferred-Value' contains the subtag of the same 'Type' that is preferred for forming the language tag. # For fields of type 'language' and 'extlang', 'Preferred-Value' contains the language production (see Figure 1 (Language Tag ABNF)) that is preferred when forming the language tag. This can be simply a 'language' subtag, or it can be a 'language' subtag followed by an extended language sequence. # For fields of type 'grandfathered' and 'redundant', a canonical mapping to a complete language tag. -- Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 18:40:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPRnG-0005Kr-Q2; Mon, 18 Sep 2006 18:40:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPRnF-0005Km-Sv for ltru@lists.ietf.org; Mon, 18 Sep 2006 18:40:49 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPRnB-0002HE-8P for ltru@lists.ietf.org; Mon, 18 Sep 2006 18:40:49 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPRmm-0005ou-1P for ltru@lists.ietf.org; Tue, 19 Sep 2006 00:40:20 +0200 Received: from pd9fba8bb.dip0.t-ipconnect.de ([217.251.168.187]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 00:40:20 +0200 Received: from nobody by pd9fba8bb.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 00:40:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 19 Sep 2006 00:38:23 +0200 Organization: Lines: 33 Message-ID: <450F1FDF.432F@xyzzy.claranet.de> References: <20060917061912.GB26073@ccil.org> <450D81D7.1070004@yahoo-inc.com> <30b660a20609171508s36585ea5r2311f0ac4c3cb2fe@mail.gmail.com> <6.0.0.20.2.20060918120033.07504ab0@localhost> <450EB359.3090006@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8bb.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [Ltru] Re: RFC 4646 production "grandfathered" considered harmful X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I intend to start with the production "irregular" shown below >>> grandfathered = irregular >>> / 1*3ALPHA 1*2("-" (2*8alphanum)) ; [...] In that version s/1*3/2*3/. If you've a good idea to split "two parts" (the 1 in 1*2) from "three parts" (the 2 in 1*2) please propose it. >>> irregular = "en-GB-oed" / "i-ami" / "i-bnn" / "i-default" >>> / "i-enochian" / "i-hak" / "i-klingon" / "i-lux" [...] >>> / "sgn-BE-fr" / "sgn-BE-nl" / "sgn-CH-de" If i-anything clearly belongs to I'm not thrilled by enumerating the 13 i-anything explicitly. 10 of the 13 are deprecated in 4645bis, only i-default, i-enochian, and i-mingo will survive. There's a registry with a museum for this cruft. Talking about unnecessary details in ABNF could backfire, e.g. if somebody decides to use i-klingon "because it's legal - as seen in ABNF". Unfortunately deprecating the complete zoo won't fly, i-default is too important. And the opposite proposal "no individually registered language subtags, register i-anything for temporary workarounds" was rejected. Are you still sure that that's as it should be ? Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 18:58:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPS3m-0003xB-1H; Mon, 18 Sep 2006 18:57:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPS3k-0003x1-Bx for ltru@lists.ietf.org; Mon, 18 Sep 2006 18:57:52 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPS3i-0005QJ-2B for ltru@lists.ietf.org; Mon, 18 Sep 2006 18:57:52 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPS3S-0001UL-UZ for ltru@lists.ietf.org; Tue, 19 Sep 2006 00:57:34 +0200 Received: from pd9fba8bb.dip0.t-ipconnect.de ([217.251.168.187]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 00:57:34 +0200 Received: from nobody by pd9fba8bb.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 00:57:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 19 Sep 2006 00:56:19 +0200 Organization: Lines: 25 Message-ID: <450F2413.4DB3@xyzzy.claranet.de> References: <021501c6db2a$2cf8cc90$6401a8c0@DGBP7M81> <450EEBB4.8000902@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8bb.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Ltru] Re: Process for creating 4646bis Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >> if the wording in Section 3.1 is changed to option (b) >> above, I'll be happy to make this change for you. Thanks - doing it individually as modification request on the language list would be a PITA, I'd have to summarize the thread here for what is in essence an irrelevant nit - unless somebody tries weird registry conversions to XML IDs. > Section 3.1 will be changed to reflect (b), as I believe this > was an oversight. ACK. And please do also something about Doug's observation: | 3.1 (which I swear is longer by itself than some RFCs) One point where you could start a 3.1.1 subsection is the statement "Each record MAY also contain the following fields". Maybe you have that already, I look into the 9-11 I-D, not your editor's copy. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 19:19:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPSON-0006AK-Gb; Mon, 18 Sep 2006 19:19:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPSOM-00069N-QP for ltru@lists.ietf.org; Mon, 18 Sep 2006 19:19:10 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPSOK-0003hl-Er for ltru@lists.ietf.org; Mon, 18 Sep 2006 19:19:10 -0400 Received: from [172.21.232.173] (wlanvpn-abc-232-173.corp.yahoo.com [172.21.232.173]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8INIqhV061934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Sep 2006 16:18:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=mDrLl1aZlYOSa9Aqb0tyAFlFEjcqYWpZn+lMypsZovpMzQAPRwTtVVkDnj9V+SsO Message-ID: <450F295C.4020207@yahoo-inc.com> Date: Mon, 18 Sep 2006 16:18:52 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: Process for creating 4646bis Registry References: <021501c6db2a$2cf8cc90$6401a8c0@DGBP7M81> <450EEBB4.8000902@yahoo-inc.com> <450F2413.4DB3@xyzzy.claranet.de> In-Reply-To: <450F2413.4DB3@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > ACK. And please do also something about Doug's observation: > > | 3.1 (which I swear is longer by itself than some RFCs) > > One point where you could start a 3.1.1 subsection is the > statement "Each record MAY also contain the following fields". > > Maybe you have that already, I look into the 9-11 I-D, not > your editor's copy. I did the former, but haven't split 3.1 yet. Putting a new
tag around some paragraphs is not very hard, but I'm not entirely sure I agree with doing a split of that section until I try it. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 19:30:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPSZc-0002Ah-Sb; Mon, 18 Sep 2006 19:30:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPSZc-0002Ab-62 for ltru@lists.ietf.org; Mon, 18 Sep 2006 19:30:48 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPSZZ-0007Xc-OY for ltru@lists.ietf.org; Mon, 18 Sep 2006 19:30:48 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPSZO-00081Z-0Q for ltru@lists.ietf.org; Tue, 19 Sep 2006 01:30:34 +0200 Received: from pd9fba8bb.dip0.t-ipconnect.de ([217.251.168.187]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 01:30:34 +0200 Received: from nobody by pd9fba8bb.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 01:30:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 19 Sep 2006 01:27:14 +0200 Organization: Lines: 40 Message-ID: <450F2B52.75B1@xyzzy.claranet.de> References: <01dc01c6dae6$cb0ae560$6401a8c0@DGBP7M81> <450E45DF.79AD@xyzzy.claranet.de> <20060918103449.GB9546@nic.fr> <021301c6db26$c7d568d0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8bb.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [Ltru] Re: zh-hakka X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org >>> For ALL prefixes, for ALL Suppress-Scripts, and for ALL >>> Preferred-Values anywhere in the registry ALL subtags of >>> the corresponding tags (or script subtags in the case of >>> Suppress-Script) are registered. JFTR, I forgot to mention ALL redundant tags. >> is it just a coincidence? > It's just a coincidence. Not really, a Prefix must consist of registered subtags, and a Suppress-script must be a registered script subtag. For a Redundant tag the name "redundant" suggests that it contains only registered subtags. The remaining wiggle room is a Preferred-Value, and Addison listed: For script + region + variant it must be a registered subtag of the same type. Ditto for language under 4646 rules, that will be extended to include extlang, but it still must be a registered language or extlang. That limits potential "coincidences" to the Preferred-Value of redundant or grandfathered. Because the grandfathered zoo is frozen you'll find that i-hak with Preferred-Value zh-hakka is the only case. It's highly unlikely (and no mere coincidence) that i-default, i-enochian, or i-mingo get a Preferred-Value pointing into the grandfathered tags. I daresay impossible. Also for all other "not yet" (state 4645bis-00pre) deprecated grandfathered tags. And I also don't see any remaining redundant tags getting a new Preferred-Value pointing into the grandfathered tags. Based on that the hakka-"coincidence" turns out to be a singularity. In theory i-default qualifies as the target of a no nonsense Preferred-Value, but in practise the 4646 rules don't allow it. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 19:44:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPSmV-0007pM-7K; Mon, 18 Sep 2006 19:44:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPSmT-0007nw-NG for ltru@lists.ietf.org; Mon, 18 Sep 2006 19:44:05 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPSmP-0004Zj-AN for ltru@lists.ietf.org; Mon, 18 Sep 2006 19:44:05 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPSmD-0002JK-VG for ltru@lists.ietf.org; Tue, 19 Sep 2006 01:43:49 +0200 Received: from pd9fbacad.dip0.t-ipconnect.de ([217.251.172.173]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 01:43:49 +0200 Received: from nobody by pd9fbacad.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 01:43:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 19 Sep 2006 01:43:08 +0200 Organization: Lines: 19 Message-ID: <450F2F0C.3042@xyzzy.claranet.de> References: <021501c6db2a$2cf8cc90$6401a8c0@DGBP7M81> <450EEBB4.8000902@yahoo-inc.com> <450F2413.4DB3@xyzzy.claranet.de> <450F295C.4020207@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbacad.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: Process for creating 4646bis Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > Putting a new
tag around some paragraphs is not > very hard It needs a nice title, e.g. "Optional fields". > I'm not entirely sure I agree with doing a split of that > section until I try it. Extract from the USEFOR-09 ToC (excl. its

sub-sections): | 3. News Header Fields | 3.1. Mandatory Header Fields | 3.2. Optional Header Fields | 3.3. Obsolete Header Fields Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 21:50:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPUkU-0006Ed-MN; Mon, 18 Sep 2006 21:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPUkS-0006Bx-JC for ltru@ietf.org; Mon, 18 Sep 2006 21:50:08 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPUkR-0008Ri-7Z for ltru@ietf.org; Mon, 18 Sep 2006 21:50:08 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GPUkL-00016u-S1; Mon, 18 Sep 2006 21:50:01 -0400 Date: Mon, 18 Sep 2006 21:50:01 -0400 To: Addison Phillips Subject: Re: [Ltru] RFC 4646 production "grandfathered" considered harmful Message-ID: <20060919015001.GP3003@ccil.org> References: <20060917061912.GB26073@ccil.org> <450D81D7.1070004@yahoo-inc.com> <30b660a20609171508s36585ea5r2311f0ac4c3cb2fe@mail.gmail.com> <6.0.0.20.2.20060918120033.07504ab0@localhost> <450EB359.3090006@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450EB359.3090006@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > >>grandfathered = irregular > >> > >> / 1*3ALPHA 1*2("-" (2*8alphanum)) ; registered > >> grandfathered codes that are well-formed, but would not > >> otherwise be valid I still don't understand the purpose of the second alternative. It matches a random subset of well-formed tags which happen to include all the grandfathered/redundant tags, but they also match "langtag", and it allows all sorts of cruft to be well-formed that will never be needed or useful. -- A rabbi whose congregation doesn't want John Cowan to drive him out of town isn't a rabbi, http://www.ccil.org/~cowan and a rabbi who lets them do it cowan@ccil.org isn't a man. --Jewish saying _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 22:39:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPVVj-0006ly-Ip; Mon, 18 Sep 2006 22:38:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPVVi-0006ls-LH for ltru@ietf.org; Mon, 18 Sep 2006 22:38:58 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPVVh-00073J-AD for ltru@ietf.org; Mon, 18 Sep 2006 22:38:58 -0400 Received: from [10.72.72.180] (snvvpn1-10-72-72-c180.corp.yahoo.com [10.72.72.180]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8J2cbGw069841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Sep 2006 19:38:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=MmlLOW54XibptT+/zn8F0CD2S3YQekiLxp0u1nIN2vXtkD0vDNCyrKKS2ZbXOiD7 Message-ID: <450F582C.4080300@yahoo-inc.com> Date: Mon, 18 Sep 2006 19:38:36 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] RFC 4646 production "grandfathered" considered harmful References: <20060917061912.GB26073@ccil.org> <450D81D7.1070004@yahoo-inc.com> <30b660a20609171508s36585ea5r2311f0ac4c3cb2fe@mail.gmail.com> <6.0.0.20.2.20060918120033.07504ab0@localhost> <450EB359.3090006@yahoo-inc.com> <20060919015001.GP3003@ccil.org> In-Reply-To: <20060919015001.GP3003@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org (laughing) In the actual editor's copy, I replaced it with 'langtag' for that reason. Addison John Cowan wrote: > Addison Phillips scripsit: > >>>> grandfathered = irregular >>>> >>>> / 1*3ALPHA 1*2("-" (2*8alphanum)) ; registered >>>> grandfathered codes that are well-formed, but would not >>>> otherwise be valid > > I still don't understand the purpose of the second alternative. > It matches a random subset of well-formed tags which happen to > include all the grandfathered/redundant tags, but they also > match "langtag", and it allows all sorts of cruft to be well-formed > that will never be needed or useful. > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 18 23:45:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPWY8-0002oZ-PC; Mon, 18 Sep 2006 23:45:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPWY7-0002jc-Hv for ltru@lists.ietf.org; Mon, 18 Sep 2006 23:45:31 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPWY5-00069C-3g for ltru@lists.ietf.org; Mon, 18 Sep 2006 23:45:31 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPWXu-000289-OI for ltru@lists.ietf.org; Tue, 19 Sep 2006 05:45:19 +0200 Received: from pd9fbacad.dip0.t-ipconnect.de ([217.251.172.173]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 05:45:18 +0200 Received: from nobody by pd9fbacad.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 05:45:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 19 Sep 2006 05:39:51 +0200 Organization: Lines: 61 Message-ID: <450F6687.32E8@xyzzy.claranet.de> References: <20060917061912.GB26073@ccil.org> <450D81D7.1070004@yahoo-inc.com> <30b660a20609171508s36585ea5r2311f0ac4c3cb2fe@mail.gmail.com> <6.0.0.20.2.20060918120033.07504ab0@localhost> <450EB359.3090006@yahoo-inc.com> <20060919015001.GP3003@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbacad.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Subject: [Ltru] Re: RFC 4646 production "grandfathered" considered harmful X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >>>> 1*3ALPHA 1*2("-" (2*8alphanum)) > I still don't understand the purpose of the second > alternative. Right, now I also see it. An enumeration is useful if it could be mistaken as well-formed "regular" tag. For a parser it's important to match some "irregular" tags _before_ it starts to match the "regular" tags. From that POV x-anything and i-anything are harmless, they're never ambiguous. And sgn-BE-nl or en-GB-oed are also not critical, they never match "regular" tags, because they're not well-formed. At some point (not necesarily a.s.a.p.) they have to match, after all they're valid. Therefore these tags could be enumerated as part of . The critical tags are well-formed grandfathered tags like zh-xiang, because there is no registered variant xiang (at the moment). You're trying to clean it up for boont and scouse, if that's accepted we end up with nine critical tags: art-lobjan, cel-gaulish, no-nyn, no-bok, zh-guoyu, zh-hakka, zh-min, zh-min-nan, zh-xiang. We're free to do whatever we like with the potential variants in those tags (declare them to be reserved, or deprecate them). We cannot preempt bok, min, nan and nyn, and they'll be used soon (probably): - bok is a future language subtag - min is a future language subtag - nan is a future extlang (and even related, good) - nyn is a future language subtag So from the 9 (or 11) critical tags we get a subset of 4 tags "no-extlang-or-not-what-you-might-expect". That results in about four subsets for an improved grandfathered ABNF: 13 i-anything, detailed ABNF enumeration unnecessary 4 extlang bogeys: no-bok, no-nyn, zh-min, zh-min-nan 5 variant bogeys: art-lobjan, cel-gaulish, etc. 2 variant bogeys which might go away before "date C" 4 less critical: en-GB-oed, and the three sgn-XX-yy If the ABNF is improved we should consider to support left-to-right depth-first matching, or in other words mention _before_ . Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 01:29:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPYAM-0006TY-AS; Tue, 19 Sep 2006 01:29:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPYAH-0006Dv-Ja for ltru@ietf.org; Tue, 19 Sep 2006 01:29:01 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPY9D-00005O-Bx for ltru@ietf.org; Tue, 19 Sep 2006 01:27:59 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GPY9C-0008EY-TK; Tue, 19 Sep 2006 01:27:54 -0400 Date: Tue, 19 Sep 2006 01:27:54 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: RFC 4646 production "grandfathered" considered harmful Message-ID: <20060919052754.GS3003@ccil.org> References: <20060917061912.GB26073@ccil.org> <450D81D7.1070004@yahoo-inc.com> <30b660a20609171508s36585ea5r2311f0ac4c3cb2fe@mail.gmail.com> <6.0.0.20.2.20060918120033.07504ab0@localhost> <450EB359.3090006@yahoo-inc.com> <20060919015001.GP3003@ccil.org> <450F6687.32E8@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450F6687.32E8@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > Right, now I also see it. An enumeration is useful if > it could be mistaken as well-formed "regular" tag. For > a parser it's important to match some "irregular" tags > _before_ it starts to match the "regular" tags. A non-validating parser doesn't have to distinguish between semantically decomposable tags and indecomposable ones with special meanings. All it has to do is have an ABNF that specifies what tags do and don't match, to which it also must add the rule against repeated singletons. For that purpose, only the irregular-syntax tags need to appear in the ABNF; the ones with regular syntax but irregular semantics do not. > From that POV x-anything and i-anything are harmless, i-anything is *not* harmless; it means that i-foobar is well-formed even though it is neither composed of valid subtags nor itself a valid grandfathered tag. i-foobar should be ill-formed. Validating parsers can use a different set of productions if it suits them better, though I don't see why it would: the simplest approach is to check for well-formedness, then check the registry to see if the tag is grandfathered, and if not, decompose them. -- John Cowan http://ccil.org/~cowan cowan@ccil.org Monday we watch-a Firefly's house, but he no come out. He wasn't home. Tuesday we go to the ball game, but he fool us. He no show up. Wednesday he go to the ball game, and we fool him. We no show up. Thursday was a double-header. Nobody show up. Friday it rained all day. There was no ball game, so we stayed home and we listened to it on-a the radio. --Chicolini _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 02:00:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPYeD-00013r-O9; Tue, 19 Sep 2006 01:59:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPYeC-00013l-K8 for ltru@ietf.org; Tue, 19 Sep 2006 01:59:56 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPYeB-0001hO-0G for ltru@ietf.org; Tue, 19 Sep 2006 01:59:56 -0400 Received: by nf-out-0910.google.com with SMTP id n15so72123nfc for ; Mon, 18 Sep 2006 22:59:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=eczktQZjpbi+SXNcXpsCQzs0b83NrqzPa5nWCPB6MC2Ikicy4q4kMlEJBodiQatnp30vgl/bOZfq1M53dD2D2tNuUEWW1I5PHNq5n+XHigvXINL7woIip802fCyJSlGiapvXLVAGrllOnIBHOXauZ6sosKM8hF/nZirJgaBUpuA= Received: by 10.49.29.2 with SMTP id g2mr17915562nfj; Mon, 18 Sep 2006 22:59:53 -0700 (PDT) Received: by 10.49.93.12 with HTTP; Mon, 18 Sep 2006 22:59:53 -0700 (PDT) Message-ID: <30b660a20609182259h1d6e4434g747835600767a0a1@mail.gmail.com> Date: Mon, 18 Sep 2006 22:59:53 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Re: RFC 4646 production "grandfathered" considered harmful In-Reply-To: <20060919052754.GS3003@ccil.org> MIME-Version: 1.0 References: <20060917061912.GB26073@ccil.org> <450D81D7.1070004@yahoo-inc.com> <30b660a20609171508s36585ea5r2311f0ac4c3cb2fe@mail.gmail.com> <6.0.0.20.2.20060918120033.07504ab0@localhost> <450EB359.3090006@yahoo-inc.com> <20060919015001.GP3003@ccil.org> <450F6687.32E8@xyzzy.claranet.de> <20060919052754.GS3003@ccil.org> X-Google-Sender-Auth: 849b69932451ef5e X-Spam-Score: 0.5 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Frank Ellermann , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0534918396==" Errors-To: ltru-bounces@ietf.org --===============0534918396== Content-Type: multipart/alternative; boundary="----=_Part_165762_31540258.1158645593477" ------=_Part_165762_31540258.1158645593477 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline A validating parser is *not* limited to all of the possible strings in the ABNF. That is already true in 4646 -- duplicate singleton extension tags are forbidden although that cannot be expressed in the ABNF. Saying that grandfathered tags are limited to i-anything is certainly an improvement on the current situation, which is: grandfathered = 1*3ALPHA 1*2("-" (2*8alphanum)) Although Frank has a point, I think my preferred approach would be to simply define but immediately deprecate subtags like lobjan -- that removes them from the grandfathered list. For the ABNF, we are then only left with the items that are syntactically ill-formed, which we could express with: grandfathered = "i-" irregularI / "sgn-" irregularSgn / irregularOther irregularI = "ami" / "bnn" / "default" / "enochian" / "hak" / "klingon" / "lux" / "mingo" / "navajo" / "pwn" / "tao" / "tay" / "tsu" irregularSgn= "BE-fr" / "BE-nl" / "CH-de" irregularOther = "en-GB-oed" We then have the smallest ABNF that (with the exception of duplicate singletons), describes the well-formed cases without letting anything else in. Mark On 9/18/06, John Cowan wrote: > > Frank Ellermann scripsit: > > > Right, now I also see it. An enumeration is useful if > > it could be mistaken as well-formed "regular" tag. For > > a parser it's important to match some "irregular" tags > > _before_ it starts to match the "regular" tags. > > A non-validating parser doesn't have to distinguish between > semantically decomposable tags and indecomposable ones with > special meanings. All it has to do is have an ABNF that > specifies what tags do and don't match, to which it also > must add the rule against repeated singletons. > > For that purpose, only the irregular-syntax tags need > to appear in the ABNF; the ones with regular syntax but > irregular semantics do not. > > > From that POV x-anything and i-anything are harmless, > > i-anything is *not* harmless; it means that i-foobar is > well-formed even though it is neither composed of valid > subtags nor itself a valid grandfathered tag. i-foobar > should be ill-formed. > > Validating parsers can use a different set of productions > if it suits them better, though I don't see why it would: > the simplest approach is to check for well-formedness, > then check the registry to see if the tag is grandfathered, > and if not, decompose them. > > -- > John Cowan http://ccil.org/~cowan cowan@ccil.org > Monday we watch-a Firefly's house, but he no come out. He wasn't home. > Tuesday we go to the ball game, but he fool us. He no show up. Wednesday > he > go to the ball game, and we fool him. We no show up. Thursday was a > double-header. Nobody show up. Friday it rained all day. There was no > ball > game, so we stayed home and we listened to it on-a the radio. --Chicolini > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_165762_31540258.1158645593477 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline A validating parser is *not* limited to all of the possible strings in the ABNF. That is already true in 4646 -- duplicate singleton extension tags are forbidden although that cannot be expressed in the ABNF.

Saying that grandfathered tags are limited to i-anything is certainly an improvement on the current situation, which is: 
 grandfathered = 1*3ALPHA 1*2("-" (2*8alphanum))
Although Frank has a point, I think my preferred approach would be to simply define but immediately deprecate subtags like lobjan -- that removes them from the grandfathered list. For the ABNF, we are then only left with the items that are syntactically ill-formed, which we could express with: 
grandfathered = "i-" irregularI
            / "sgn-" irregularSgn
            / irregularOther
irregularI = "ami" / "bnn" / "default" / "enochian" / "hak" / "klingon" / "lux" / "mingo" / "navajo" / "pwn" / "tao" / "tay" / "tsu"
irregularSgn= "BE-fr" / "BE-nl" / "CH-de"
irregularOther = "en-GB-oed"

We then have the smallest ABNF that (with the exception of duplicate singletons), describes the well-formed cases without letting anything else in.

Mark

On 9/18/06, John Cowan <cowan@ccil.org> wrote:
Frank Ellermann scripsit:

> Right, now I also see it.  An enumeration is useful if
> it could be mistaken as well-formed "regular" tag.  For
> a parser it's important to match some "irregular" tags
> _before_ it starts to match the "regular" tags.

A non-validating parser doesn't have to distinguish between
semantically decomposable tags and indecomposable ones with
special meanings.  All it has to do is have an ABNF that
specifies what tags do and don't match, to which it also
must add the rule against repeated singletons.

For that purpose, only the irregular-syntax tags need
to appear in the ABNF; the ones with regular syntax but
irregular semantics do not.

>  From that POV x-anything and i-anything are harmless,

i-anything is *not* harmless; it means that i-foobar is
well-formed even though it is neither composed of valid
subtags nor itself a valid grandfathered tag.  i-foobar
should be ill-formed.

Validating parsers can use a different set of productions
if it suits them better, though I don't see why it would:
the simplest approach is to check for well-formedness,
then check the registry to see if the tag is grandfathered,
and if not, decompose them.

--
John Cowan     http://ccil.org/~cowan    cowan@ccil.org
Monday we watch-a Firefly's house, but he no come out.  He wasn't home.
Tuesday we go to the ball game, but he fool us.  He no show up.  Wednesday he
go to the ball game, and we fool him.  We no show up.  Thursday was a
double-header.  Nobody show up.  Friday it rained all day.  There was no ball
game, so we stayed home and we listened to it on-a the radio.  --Chicolini

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

------=_Part_165762_31540258.1158645593477-- --===============0534918396== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0534918396==-- From ltru-bounces@ietf.org Tue Sep 19 02:02:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPYgO-0001Mt-RH; Tue, 19 Sep 2006 02:02:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPYgN-0001Mn-IC for ltru@ietf.org; Tue, 19 Sep 2006 02:02:11 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPYgM-00029V-Aw for ltru@ietf.org; Tue, 19 Sep 2006 02:02:11 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060919060207.NAWO17675.mta9.adelphia.net@DGBP7M81>; Tue, 19 Sep 2006 02:02:07 -0400 Message-ID: <004501c6dbb1$23d1bc80$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <021501c6db2a$2cf8cc90$6401a8c0@DGBP7M81> <450EEBB4.8000902@yahoo-inc.com> Subject: Re: [Ltru] Re: Process for creating 4646bis Registry Date: Mon, 18 Sep 2006 23:02:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >> Seriously, I think this passage is in error with respect to "tags" >> and needs to be modified to say that redundant tags are either: >> ... >> (b) cased as if they were composed of individual subtags, using the >> casing conventions for those subtags (what you want). > > Section 3.1 will be changed to reflect (b), as I believe this was an > oversight. I will specifically mention this in 4645bis, since otherwise it would be a "silent change." -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 02:09:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPYn8-0006cF-Up; Tue, 19 Sep 2006 02:09:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPYn7-0006bF-Qp for ltru@ietf.org; Tue, 19 Sep 2006 02:09:09 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPYn6-000300-J9 for ltru@ietf.org; Tue, 19 Sep 2006 02:09:09 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060919060907.LXEU14728.mta10.adelphia.net@DGBP7M81>; Tue, 19 Sep 2006 02:09:07 -0400 Message-ID: <004701c6dbb2$1e6699e0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <01dc01c6dae6$cb0ae560$6401a8c0@DGBP7M81> <450E45DF.79AD@xyzzy.claranet.de> <20060918103449.GB9546@nic.fr> <021301c6db26$c7d568d0$6401a8c0@DGBP7M81> <450EEE81.70603@yahoo-inc.com> Subject: Re: [Ltru] Re: zh-hakka Date: Mon, 18 Sep 2006 23:09:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Frank Ellermann X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > It's a coincidence, but one that is desirable. In other words, I think > it would be a Bad Thing to deprecate some value in favor of a > grandfathered tag in the post-RFC 4646 era. Of course it would. Nobody's proposing to do this in the future. We are talking about the situation with "zh-hakka", which became the Preferred-Value for "i-hak" (except we didn't call it that) back in the RFC 1766 era. It's not going to be partitioned into language + variant (unlike "en-boont") because we know the language is covered by ISO 639-3. This situation could not happen again. > In fact, the rules explicitly allow a Preferred-Value to be a tag, if > the thing being deprecated is a grandfathered item. In 4646bis, for > example, it says: > ... > # For fields of type 'grandfathered' and 'redundant', a canonical > mapping to a complete language tag. I did cite that. We know the P-V for deprecated tag "A" must be another tag -- the question is whether tag "B" can be a grandfathered tag. And the answer is, of course it can, as long as tag "B" replaced tag "A" before the RFC 4646 era. That is exactly what happened with "zh-hakka". -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 02:18:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPYwN-00037j-SW; Tue, 19 Sep 2006 02:18:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPYwM-00037d-Lo for ltru@ietf.org; Tue, 19 Sep 2006 02:18:42 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPYwL-0005Np-EV for ltru@ietf.org; Tue, 19 Sep 2006 02:18:42 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060919061840.MAWH14728.mta10.adelphia.net@DGBP7M81> for ; Tue, 19 Sep 2006 02:18:40 -0400 Message-ID: <004d01c6dbb3$73d9f290$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 18 Sep 2006 23:18:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Re: RFC 4646 production "grandfathered" considered harmful X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > Unfortunately deprecating the complete zoo won't fly, i-default is too > important. And the opposite proposal "no individually registered > language subtags, register i-anything for temporary workarounds" was > rejected. Are you still sure that that's as it should be ? The grammar really has nothing to do with what's deprecated and what's not. Deprecated tags and subtags are still valid, and still have to appear in the ABNF somehow. Our idea of "deprecated" isn't nearly as strong as in some other standards, such as ISO 3166 ("stop using ASAP"). -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 02:30:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPZ7W-00023B-3h; Tue, 19 Sep 2006 02:30:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPZ7U-000236-Sm for ltru@ietf.org; Tue, 19 Sep 2006 02:30:12 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPZ7T-0008ML-Ka for ltru@ietf.org; Tue, 19 Sep 2006 02:30:12 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060919063011.NKQY17675.mta9.adelphia.net@DGBP7M81> for ; Tue, 19 Sep 2006 02:30:11 -0400 Message-ID: <005301c6dbb5$0f4ce920$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 18 Sep 2006 23:30:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Ltru] Re: zh-hakka X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > That limits potential "coincidences" to the Preferred-Value of > redundant or grandfathered. Because the grandfathered zoo is frozen > you'll find that i-hak with Preferred-Value zh-hakka is the only case. > > It's highly unlikely (and no mere coincidence) that i-default, > i-enochian, or i-mingo get a Preferred-Value pointing into the > grandfathered tags. I daresay impossible. Also for all other "not > yet" (state 4645bis-00pre) deprecated grandfathered tags. > > And I also don't see any remaining redundant tags getting a new > Preferred-Value pointing into the grandfathered tags. Based on that > the hakka-"coincidence" turns out to be a singularity. I really don't understand what the big deal is concerning "zh-hakka". The only reason it is different in any way from "zh-guoyu", or for that matter "zh-xiang", is that there was a prior registration under RFC 1766 for the same language ("i-hak"). January 1999: "i-hak" is registered. December 1999: "zh-hakka" is registered. January 2000: "i-hak" is deprecated in favor of "zh-hakka". January 2001: RFC 3066 is published, replacing RFC 1766. Under RFC 1766 and 3066 there was nothing unusual about the idea of one registered tag being deprecated in favor of another registered tag. Nobody has proposed that *more* tags should be deprecated in favor of grandfathered tags -- that could not happen in the RFC 4646 era by definition. The situation with Hakka, plain and simple, is that "i-hak" was deprecated in favor of "zh-hakka" almost seven years ago, and now both tags are grandfathered into 4646, and "zh-hakka" is about to be deprecated in favor of an ISO 639-3-based language/extlang combination. It would be preposterous to register a variant "hakka" just to satisfy a 4646 grammar rule that never existed. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 05:28:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPbtW-0002yE-1D; Tue, 19 Sep 2006 05:27:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPbtU-0002y4-D0 for ltru@lists.ietf.org; Tue, 19 Sep 2006 05:27:56 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPbtP-0004p1-Ix for ltru@lists.ietf.org; Tue, 19 Sep 2006 05:27:56 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8J9Rn3d001578 for ; Tue, 19 Sep 2006 18:27:49 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 76be_1e3386ce_47c1_11db_93cc_0014221fa3c9; Tue, 19 Sep 2006 18:27:49 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:36549) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 19 Sep 2006 18:27:53 +0900 Message-Id: <6.0.0.20.2.20060919182458.02434ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 19 Sep 2006 18:26:40 +0900 To: Stephane Bortzmeyer From: Martin Duerst In-Reply-To: <20060918074409.GB16778@nic.fr> References: <6.0.0.20.2.20060918111628.08943ec0@localhost> <20060918074409.GB16778@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Frank Ellermann , ltru@lists.ietf.org Subject: [Ltru] Re: [Partially OT] DOCTYPE ltru X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Stephane, I have explicitly not said that the discussion of an alternative XML format should be moved off the list, because I, too, think that it is valuable to have such discussions. I have just asked that they be marked with [OT] to help people who are overwhelmed by the number of mails. Regards, Martin. At 16:44 06/09/18, Stephane Bortzmeyer wrote: >On Mon, Sep 18, 2006 at 11:17:38AM +0900, > Martin Duerst wrote > a message of 127 lines which said: > >> As a co-chair, I marked this off-topic, unless I misunderstood you >> to make this as a proposal for the actual registry. > >I do not think that Frank wanted XML to be the official format :-) > >Nevertheless, I find quite useful, even if it is officially OT, to >discuss here about alternative formats (my proposal to host somewhere, >in an unofficial site, the translations to other formats) or about >implementations (such as Mark's regexp). > >Yes, it is not in the WG charter but tackling practical problems is >also a good way to test the standard and to improve it. > >If the chairs insist :-) may be we could create a dedicated mailing >list, "ltru-implementors" but I would regard this as useless >duplication. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 05:49:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPcEL-0008RQ-Vq; Tue, 19 Sep 2006 05:49:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPcEK-0008RI-KY for ltru@lists.ietf.org; Tue, 19 Sep 2006 05:49:28 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPcEJ-0000Wf-89 for ltru@lists.ietf.org; Tue, 19 Sep 2006 05:49:28 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPcDx-0003JK-8I for ltru@lists.ietf.org; Tue, 19 Sep 2006 11:49:05 +0200 Received: from pd9fba92d.dip0.t-ipconnect.de ([217.251.169.45]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 11:49:05 +0200 Received: from nobody by pd9fba92d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 11:49:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 19 Sep 2006 11:48:19 +0200 Organization: Lines: 13 Message-ID: <450FBCE3.4CA5@xyzzy.claranet.de> References: <6.0.0.20.2.20060918111628.08943ec0@localhost> <20060918074409.GB16778@nic.fr> <6.0.0.20.2.20060919182458.02434ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba92d.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] Re: [Partially OT] DOCTYPE ltru X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > I have just asked that they be marked with [OT] to help > people who are overwhelmed by the number of mails. Oops, that wasn't clear for me. Different net cultures with different netiquettes - the subject tag [OT] often implies "ought to be moved to another group or list or private mail a.s.a.p.". I've heard that it used to have your intended meaning in MAUSNET. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 08:12:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPeSg-0003yy-Cc; Tue, 19 Sep 2006 08:12:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPeSf-0003yd-6I for ltru@lists.ietf.org; Tue, 19 Sep 2006 08:12:25 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPeSa-0000hY-T0 for ltru@lists.ietf.org; Tue, 19 Sep 2006 08:12:25 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 450DB26C207; Tue, 19 Sep 2006 14:12:10 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 87AA826C19E; Tue, 19 Sep 2006 14:12:08 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 8256558ED1C; Tue, 19 Sep 2006 14:12:08 +0200 (CEST) Date: Tue, 19 Sep 2006 14:12:08 +0200 From: Stephane Bortzmeyer To: Mark Davis Message-ID: <20060919121208.GA20171@nic.fr> References: <20060802072709.GA17404@nic.fr> <44D21ACD.4040707@yahoo-inc.com> <20060804165720.GA24037@sources.org> <44D4AC42.79E0@xyzzy.claranet.de> <20060830093000.GA31895@nic.fr> <44F6313D.2070000@yahoo-inc.com> <6.0.0.20.2.20060831201004.101ab8d0@localhost> <44F6EF0E.20602@yahoo-inc.com> <6.0.0.20.2.20060901024806.109a6d90@localhost> <30b660a20609161628t22ab3c4flc81ea92f40800a09@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20609161628t22ab3c4flc81ea92f40800a09@mail.gmail.com> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sat, Sep 16, 2006 at 04:28:01PM -0700, Mark Davis wrote a message of 98 lines which said: > and a test file that includes strings mentioned on this list is at: > > http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagTest.txt May I ask a question about some of the tags in this file? xE-Lxs-qu is indicated as well-formed but I do not think so. Because of "Lxs", it can only be and extension and therefore, "qu" is forbidden (xE-Lxs is well-formed, as well as xE-Lxs-quT). (There are in your file several other tags with 2letters then 3letters, which have the same problem.) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 08:31:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPel4-00074x-Pc; Tue, 19 Sep 2006 08:31:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPel3-00074s-Nq for ltru@ietf.org; Tue, 19 Sep 2006 08:31:25 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPel2-0005RA-HZ for ltru@ietf.org; Tue, 19 Sep 2006 08:31:25 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GPel2-0004jF-69; Tue, 19 Sep 2006 08:31:24 -0400 Date: Tue, 19 Sep 2006 08:31:24 -0400 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: Test suite for language tags? Message-ID: <20060919123124.GW3003@ccil.org> References: <44D21ACD.4040707@yahoo-inc.com> <20060804165720.GA24037@sources.org> <44D4AC42.79E0@xyzzy.claranet.de> <20060830093000.GA31895@nic.fr> <44F6313D.2070000@yahoo-inc.com> <6.0.0.20.2.20060831201004.101ab8d0@localhost> <44F6EF0E.20602@yahoo-inc.com> <6.0.0.20.2.20060901024806.109a6d90@localhost> <30b660a20609161628t22ab3c4flc81ea92f40800a09@mail.gmail.com> <20060919121208.GA20171@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060919121208.GA20171@nic.fr> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer scripsit: > xE-Lxs-qu is indicated as well-formed but I do not think so. Because > of "Lxs", it can only be and extension and therefore, "qu" is > forbidden (xE-Lxs is well-formed, as well as xE-Lxs-quT). No, it's well-formed all right: language-extlang-region. Nothing wrong with that, as in "zh-hak-TW", the variety of Hakka Chinese spoken on Taiwan. Of course it won't be valid until 4646bis. -- What asininity could I have uttered John Cowan that they applaud me thus? http://www.ccil.org/~cowan --Phocion, Greek orator _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 08:55:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPf7x-00011q-5X; Tue, 19 Sep 2006 08:55:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPf7w-0000zk-Ah for ltru@ietf.org; Tue, 19 Sep 2006 08:55:04 -0400 Received: from eve.generic-nic.net ([192.134.7.250] helo=mail.generic-nic.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPf7b-0000x8-8w for ltru@ietf.org; Tue, 19 Sep 2006 08:54:47 -0400 Received: from sarah.generic-nic.net (sarah.generic-nic.net [192.134.7.249]) by mail.generic-nic.net (Postfix) with ESMTP id 1DAF822B2DA for ; Tue, 19 Sep 2006 14:54:24 +0200 (CEST) Received: by sarah.generic-nic.net (Postfix, from userid 1000) id ED30F837D4; Tue, 19 Sep 2006 14:54:23 +0200 (CEST) Date: Tue, 19 Sep 2006 14:54:23 +0200 From: Stephane Bortzmeyer To: ltru@ietf.org Message-ID: <20060919125423.GA14527@generic-nic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Generic NIC X-URL: http://www.generic-nic.net/ X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.12 i686 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Ltru] [OT] A language tag parser X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Let me advertise boldly my language tag parser : http://www.bortzmeyer.org/gabuzomeu-parsing-language-tags.html It is free software, so feel free to play with it. It has many bugs, so I'm sure to get a lot of reports :-) Are there any other publically released language tag parsers? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 08:55:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPf8C-0001Fk-It; Tue, 19 Sep 2006 08:55:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPf83-00018G-JI for ltru@ietf.org; Tue, 19 Sep 2006 08:55:11 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPf0l-00005i-4r for ltru@ietf.org; Tue, 19 Sep 2006 08:47:42 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8JClb3B008782 for ; Tue, 19 Sep 2006 21:47:37 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 778b_0754dc8e_47dd_11db_8bdb_0014221fa3c9; Tue, 19 Sep 2006 21:47:37 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:43979) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 19 Sep 2006 21:47:41 +0900 Message-Id: <6.0.0.20.2.20060919211635.076d4ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 19 Sep 2006 21:18:34 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: zh-hakka In-Reply-To: <005301c6dbb5$0f4ce920$6401a8c0@DGBP7M81> References: <005301c6dbb5$0f4ce920$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 15:30 06/09/19, Doug Ewell wrote: >The situation with Hakka, plain and simple, is that "i-hak" was deprecated in favor of "zh-hakka" almost seven years ago, and now both tags are grandfathered into 4646, and "zh-hakka" is about to be deprecated in favor of an ISO 639-3-based language/extlang combination. It would be preposterous to register a variant "hakka" just to satisfy a 4646 grammar rule that never existed. Somewhat unrelated: My understanding is that currently 'preferred' value pointers are as follows: i-hak -> zh-hakka zh-hakka -> zh-hak I think the following would be preferable: i-hak -> zh-hak zh-hakka -> zh-hak This would avoid the need for repetition when calculating the preferred value. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 09:34:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfjV-0006iG-Bf; Tue, 19 Sep 2006 09:33:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfjU-0006iB-J7 for ltru@ietf.org; Tue, 19 Sep 2006 09:33:52 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPfjT-0005TQ-Bq for ltru@ietf.org; Tue, 19 Sep 2006 09:33:52 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060919133350.YHLI17675.mta9.adelphia.net@DGBP7M81>; Tue, 19 Sep 2006 09:33:50 -0400 Message-ID: <007501c6dbf0$3e799ff0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <005301c6dbb5$0f4ce920$6401a8c0@DGBP7M81> <6.0.0.20.2.20060919211635.076d4ec0@localhost> Subject: Re: [Ltru] Re: zh-hakka Date: Tue, 19 Sep 2006 06:33:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > My understanding is that currently 'preferred' value pointers are as > follows: > > i-hak -> zh-hakka > zh-hakka -> zh-hak > > I think the following would be preferable: > > i-hak -> zh-hak > zh-hakka -> zh-hak > > This would avoid the need for repetition when calculating the > preferred value. Preferred-Values aren't allowed to change once they are assigned. There was a stability reason for this. I think Mark can probably address that. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 09:34:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfk3-0006x3-LD; Tue, 19 Sep 2006 09:34:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfk2-0006w5-5n for ltru@lists.ietf.org; Tue, 19 Sep 2006 09:34:26 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPfjz-0005fw-Sa for ltru@lists.ietf.org; Tue, 19 Sep 2006 09:34:26 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPfjd-0001X7-M7 for ltru@lists.ietf.org; Tue, 19 Sep 2006 15:34:01 +0200 Received: from pd9fba92d.dip0.t-ipconnect.de ([217.251.169.45]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 15:34:01 +0200 Received: from nobody by pd9fba92d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 15:34:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 19 Sep 2006 15:32:40 +0200 Organization: Lines: 24 Message-ID: <450FF178.190F@xyzzy.claranet.de> References: <005301c6dbb5$0f4ce920$6401a8c0@DGBP7M81> <6.0.0.20.2.20060919211635.076d4ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba92d.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] Re: zh-hakka X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > i-hak -> zh-hakka > zh-hakka -> zh-hak > I think the following would be preferable: > i-hak -> zh-hak > zh-hakka -> zh-hak Yes. It would also eliminate the only pointer containing a "non-variant". We discussed this in the last round, I don't recall the arguments against it. Maybe the more convoluted 4646 pointers were inspired by UnicodeData.txt (?) > This would avoid the need for repetition when calculating > the preferred value. It also simplifies pointer checks, there's never a danger of A -> B -> C -> A, if A *_must_* point to something that has no further pointer. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 09:40:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfpR-000391-Ck; Tue, 19 Sep 2006 09:40:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfpP-00038s-I9 for ltru@ietf.org; Tue, 19 Sep 2006 09:39:59 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPfpM-000792-NO for ltru@ietf.org; Tue, 19 Sep 2006 09:39:59 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8JDdtPf013022 for ; Tue, 19 Sep 2006 22:39:55 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 124f_55a74078_47e4_11db_9c46_0014221f2a2d; Tue, 19 Sep 2006 22:39:54 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:48039) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 19 Sep 2006 22:39:57 +0900 Message-Id: <6.0.0.20.2.20060919220242.09c4a540@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 19 Sep 2006 22:04:08 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: UTF-8 In-Reply-To: <01c601c6dade$0333d040$6401a8c0@DGBP7M81> References: <011e01c6da79$b7f17330$6401a8c0@DGBP7M81> <6.0.0.20.2.20060918124446.07506d80@localhost> <01c601c6dade$0333d040$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org It seems that a third alternative would be to give the sources a hint that they might want to do a little cleanup. But I guess somebody has thought about that, and somebody has tried it. Regards, Martin. At 13:50 06/09/18, Doug Ewell wrote: >Martin Duerst wrote: > >> I agree. Frank said we should just use what the source uses, but officially, the soure in most cases still is paper. > >As much for the archives as for Martin: > >The question of "use what the source uses" is a long-standing, divisive one. The sources for the 4646 Registry were electronic: code lists found on the home pages of the ISO MA's and on the UNSD site. Sometimes these appeared inconsistent, with themselves and particularly with each other, on things like apostrophe usage. Sometimes they yielded bizarre results, like the acute accent (U+00B4) used in the name Gwich'in. > >There are WG members (and ietf-languages contributors) who feel very strongly that the Description fields in the Registry must match the source standards exactly, to enable automated cross-referencing and generally to avoid arbitrariness. Then there are WG members (and ietf-languages contributors) who feel equally strongly that we should be able to improve on the names, either typographically or to improve clarity and avoid ambiguity. These two groups are at polar opposites and the only way to satisfy both is to admit both Descriptions, even when the end result seems preposterous. > >-- >Doug Ewell >Fullerton, California, USA >http://users.adelphia.net/~dewell/ >RFC 4645 * UTN #14 > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 09:40:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfpr-0003Im-Ro; Tue, 19 Sep 2006 09:40:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfpq-0003Ih-KY for ltru@ietf.org; Tue, 19 Sep 2006 09:40:26 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPfpl-0007BW-UT for ltru@ietf.org; Tue, 19 Sep 2006 09:40:26 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8JDeKQf021054 for ; Tue, 19 Sep 2006 22:40:20 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 128a_64d14102_47e4_11db_8cfc_0014221f2a2d; Tue, 19 Sep 2006 22:40:19 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:48039) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 19 Sep 2006 22:40:23 +0900 Message-Id: <6.0.0.20.2.20060919221647.09c4d170@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 19 Sep 2006 22:17:58 +0900 To: Peter Constable , LTRU Working Group From: Martin Duerst Subject: RE: [Ltru] Re: UTF-8 In-Reply-To: References: <6.0.0.20.2.20060917165059.08a0ed10@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [chair hat on] Peter, with the observation below, do you want to say you are in favor of moving to UTF-8, or against, or did you write that strictly as an observation only? Regards, Martin. At 16:04 06/09/18, Peter Constable wrote: >> From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > > >> Agreed. In my point of view, the pain of Bokm&#$!@*l outweights >> a lot of things. The main benefit is that native people can >> easily check that things are correct, which they won't do >> if we show them just a number. > >There's lots of software that will interpret an NCR in an HTML, XML or HTML >file and display it to the user as the actual character in the UCS for >which it is a reference. I don't think there is any software that will do >this for the file located at >http://www.iana.org/assignments/language-subtag-registry. > > > > >Peter Constable #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 09:40:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfq8-0003OB-09; Tue, 19 Sep 2006 09:40:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfq6-0003O3-KQ for ltru@ietf.org; Tue, 19 Sep 2006 09:40:42 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPfq5-0007Ec-17 for ltru@ietf.org; Tue, 19 Sep 2006 09:40:42 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8JDeeJw021062 for ; Tue, 19 Sep 2006 22:40:40 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 128a_704e4a0c_47e4_11db_8cfc_0014221f2a2d; Tue, 19 Sep 2006 22:40:39 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:48039) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 19 Sep 2006 22:40:42 +0900 Message-Id: <6.0.0.20.2.20060919221943.09c54e30@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 19 Sep 2006 22:21:33 +0900 To: "Jukka K. Korpela" , ltru@ietf.org From: Martin Duerst Subject: RE: [Ltru] Re: script tag for IPA In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 15:58 06/09/18, Jukka K. Korpela wrote: >On Sun, 17 Sep 2006, Peter Constable wrote: >> I suppose one could use IPA notation to cite an abstracted utterance. Abstracted usage -- i.e. independent of any language -- is often done when discussing individual phonemes, but I don't know that I've ever seen a single instance of a transcription of an abstracted utterance. > >Just to clarify: I did not mean an abstract utterance Talking about abstract utterances, the sounds produced by our six month old doughter could be an interesting source, but I doubt IPA could cover all of them, and I'm not eough of an IPA user to actually try to write some of them down :-). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 09:40:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfqN-0003RY-4W; Tue, 19 Sep 2006 09:40:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfqL-0003RS-EC for ltru@lists.ietf.org; Tue, 19 Sep 2006 09:40:57 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPfqJ-0007Gg-FF for ltru@lists.ietf.org; Tue, 19 Sep 2006 09:40:57 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8JDesfk021080 for ; Tue, 19 Sep 2006 22:40:54 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 124e_78cbfa58_47e4_11db_9b11_0014221f2a2d; Tue, 19 Sep 2006 22:40:54 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:48039) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 19 Sep 2006 22:40:53 +0900 Message-Id: <6.0.0.20.2.20060919222601.09c56ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 19 Sep 2006 22:33:34 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Process for creating 4646bis Registry In-Reply-To: <450E3D54.39C1@xyzzy.claranet.de> References: <018701c6dab1$3ef889e0$6401a8c0@DGBP7M81> <450E3D54.39C1@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 15:31 06/09/18, Frank Ellermann wrote: >Doug Ewell wrote: > >> I'm trying to gauge consensus myself, and we know how >> dangerous it can be when individual members start doing that. > >That's editorial freedom, if we don't like the result we can >disccuss it. [co-chair hat on] Yes indeed. >> We'd better decide this pivotal question soon. > >For the initial draft stick to your choice, [co-chair hat on] Yes, please. It's easier to discuss an actual draft (or potentially some data hanging off an actual draft but verifiably so) than some proposals in emails. >> IMHO it would be more of an error if we "corrected" the case >> of a previously registered tag; the whole point of keeping >> redundant tags in the Registry is to preserve them in a >> museum-like setting. > >The museum survives it if one yi-latn is fixed to yi-Latn. :-) [co-chair hat off] I agree with Frank here. Somebody had to be the first to come up with the idea of using XML idrefs for cross-checking, and unfortunately, it didn't happen before RFC 464x. And because case is officially and completely irrelevant, I don't see a point in the 'museum' preserving it. And for historians, http://www.iana.org/assignments/language-tags is still online at the moment, and our mails serve as another witness to that specific bit of language tag history. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 09:58:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPg6p-0004xo-KY; Tue, 19 Sep 2006 09:57:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPg6o-0004xM-4O for ltru@ietf.org; Tue, 19 Sep 2006 09:57:58 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPfuC-0008Kl-1z for ltru@ietf.org; Tue, 19 Sep 2006 09:44:57 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060919134455.WFDH25133.mta11.adelphia.net@DGBP7M81> for ; Tue, 19 Sep 2006 09:44:55 -0400 Message-ID: <007c01c6dbf1$cad3d780$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 19 Sep 2006 06:44:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Ltru] Re: RFC 4646 production "grandfathered" considered harmful X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > Although Frank has a point, I think my preferred approach would be to > simply define but immediately deprecate subtags like lobjan -- that > removes them from the grandfathered list. For the ABNF, we are then > only left with the items that are syntactically ill-formed, which we > could express with: > > grandfathered = "i-" irregularI > / "sgn-" irregularSgn > / irregularOther > > irregularI = "ami" / "bnn" / "default" / "enochian" / "hak" / > "klingon" / "lux" / "mingo" / "navajo" / "pwn" / "tao" / "tay" / "tsu" > irregularSgn= "BE-fr" / "BE-nl" / "CH-de" > irregularOther = "en-GB-oed" > > We then have the smallest ABNF that (with the exception of duplicate > singletons), describes the well-formed cases without letting anything > else in. I think creating more deprecated-at-birth subtags is a terrible idea. As you showed, it doesn't even simplify the ABNF -- you still have the messy "irregularOther" production. It reduces the size of the list in the ABNF, but increases the amount of trash in the Registry. The ABNF can't cover every possible syntactical tagging rule anyway; consider en-b-bbb-a-aaa. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 10:18:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPgQv-00072i-9C; Tue, 19 Sep 2006 10:18:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPgQt-00070o-4u for ltru@ietf.org; Tue, 19 Sep 2006 10:18:43 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPgQr-0000h2-O4 for ltru@ietf.org; Tue, 19 Sep 2006 10:18:43 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060919141841.YZPO14728.mta10.adelphia.net@DGBP7M81> for ; Tue, 19 Sep 2006 10:18:41 -0400 Message-ID: <008601c6dbf6$8238dc00$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 19 Sep 2006 07:18:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ltru] Re: zh-hakka X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> This would avoid the need for repetition when calculating the >> preferred value. > > It also simplifies pointer checks, there's never a danger of A -> B -> > C -> A, if A *_must_* point to something that has no further pointer. I think we are again trying to legislate against the unthinkable. Once the Registry has been created, only newly formed subtags (and tags composed from them) get to be Preferred-Values. There is no reasonable chance that ietf-languages will ever make an older (sub)tag the Preferred-Value for a newer one. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 10:18:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPgQr-0006xN-M0; Tue, 19 Sep 2006 10:18:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPgQq-0006we-JQ for ltru@ietf.org; Tue, 19 Sep 2006 10:18:40 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPgO6-0008Sg-27 for ltru@ietf.org; Tue, 19 Sep 2006 10:15:51 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060919141545.YUNA14728.mta10.adelphia.net@DGBP7M81> for ; Tue, 19 Sep 2006 10:15:45 -0400 Message-ID: <008201c6dbf6$195ad9e0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 19 Sep 2006 07:15:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > xE-Lxs-qu is indicated as well-formed but I do not think so. Because > of "Lxs", it can only be and extension and therefore, "qu" is > forbidden (xE-Lxs is well-formed, as well as xE-Lxs-quT). Be careful not to confuse "extended language" or "extlang" subtags, which are 3 letters, with "extension" subtags, which cannot appear before a region. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 10:58:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPh3X-0003FT-BF; Tue, 19 Sep 2006 10:58:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPh0d-0001uF-88 for ltru@lists.ietf.org; Tue, 19 Sep 2006 10:55:39 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPgqb-0003iZ-1G for ltru@lists.ietf.org; Tue, 19 Sep 2006 10:45:18 -0400 Received: from [10.72.72.180] (snvvpn1-10-72-72-c180.corp.yahoo.com [10.72.72.180]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8JEj5W7094950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Sep 2006 07:45:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=YwEJ8tKwrNQ+lKxyYs2HBNeVIzcr94Yh8pccYzkZPGrCvLU+ettoS+/aYry67eXd Message-ID: <45100271.5090407@yahoo-inc.com> Date: Tue, 19 Sep 2006 07:45:05 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: Test suite for language tags? References: <20060802072709.GA17404@nic.fr> <44D21ACD.4040707@yahoo-inc.com> <20060804165720.GA24037@sources.org> <44D4AC42.79E0@xyzzy.claranet.de> <20060830093000.GA31895@nic.fr> <44F6313D.2070000@yahoo-inc.com> <6.0.0.20.2.20060831201004.101ab8d0@localhost> <44F6EF0E.20602@yahoo-inc.com> <6.0.0.20.2.20060901024806.109a6d90@localhost> <30b660a20609161628t22ab3c4flc81ea92f40800a09@mail.gmail.com> <20060919121208.GA20171@nic.fr> In-Reply-To: <20060919121208.GA20171@nic.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > On Sat, Sep 16, 2006 at 04:28:01PM -0700, > Mark Davis wrote > a message of 98 lines which said: > >> and a test file that includes strings mentioned on this list is at: >> >> http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagTest.txt > > May I ask a question about some of the tags in this file? > > xE-Lxs-qu is indicated as well-formed but I do not think so. Because > of "Lxs", it can only be and extension and therefore, "qu" is > forbidden (xE-Lxs is well-formed, as well as xE-Lxs-quT). "Lxs" would be an extlang and "qu" would be a region. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 10:59:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPh4f-00043Q-Ly; Tue, 19 Sep 2006 10:59:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPh4e-00043L-K1 for ltru@lists.ietf.org; Tue, 19 Sep 2006 10:59:48 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPh4d-0005jc-9E for ltru@lists.ietf.org; Tue, 19 Sep 2006 10:59:48 -0400 Received: from [10.72.72.180] (snvvpn1-10-72-72-c180.corp.yahoo.com [10.72.72.180]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8JExai3095475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Sep 2006 07:59:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=oQeRE6TTzdHrMQp+4XEpoOZvu1USBlNoEJ1hhxHs14zp3fZjG7UogU/K6+2IVFhn Message-ID: <451005D8.1070507@yahoo-inc.com> Date: Tue, 19 Sep 2006 07:59:36 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: zh-hakka References: <005301c6dbb5$0f4ce920$6401a8c0@DGBP7M81> <6.0.0.20.2.20060919211635.076d4ec0@localhost> <450FF178.190F@xyzzy.claranet.de> In-Reply-To: <450FF178.190F@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > Martin Duerst wrote: > >> i-hak -> zh-hakka >> zh-hakka -> zh-hak > >> I think the following would be preferable: > >> i-hak -> zh-hak >> zh-hakka -> zh-hak > > Yes. It would also eliminate the only pointer containing a > "non-variant". We discussed this in the last round, I don't > recall the arguments against it. Maybe the more convoluted > 4646 pointers were inspired by UnicodeData.txt (?) I don't understand. Why is it important that a pointer contain a variant? > >> This would avoid the need for repetition when calculating >> the preferred value. > > It also simplifies pointer checks, there's never a danger of > A -> B -> C -> A, if A *_must_* point to something that has > no further pointer. > But we don't want to enshrine that in the rules, do we? I don't think it is necessary to require that pointers have only a depth of 1 in the registry. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 11:03:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPh8N-0000mr-80; Tue, 19 Sep 2006 11:03:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPh8M-0000kh-0Z for ltru@ietf.org; Tue, 19 Sep 2006 11:03:38 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPh8K-0006Do-MR for ltru@ietf.org; Tue, 19 Sep 2006 11:03:37 -0400 Received: from [10.72.72.180] (snvvpn1-10-72-72-c180.corp.yahoo.com [10.72.72.180]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8JF3UBh095645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Sep 2006 08:03:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=JnEqr51/0ITwpykJMfxII8szbIz/qNkpUEg9mw8NsCm1cO2BDrSpeFWGM95Tf+EH Message-ID: <451006C2.60603@yahoo-inc.com> Date: Tue, 19 Sep 2006 08:03:30 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: zh-hakka References: <008601c6dbf6$8238dc00$6401a8c0@DGBP7M81> In-Reply-To: <008601c6dbf6$8238dc00$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > There is no reasonable > chance that ietf-languages will ever make an older (sub)tag the > Preferred-Value for a newer one. > That might not turn out to be true. For example, sometimes countries merge together. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 11:07:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhBm-0002hN-8A; Tue, 19 Sep 2006 11:07:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhBk-0002gv-NX for ltru@ietf.org; Tue, 19 Sep 2006 11:07:08 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPhBi-0006hT-B5 for ltru@ietf.org; Tue, 19 Sep 2006 11:07:08 -0400 Received: from [10.72.72.180] (snvvpn1-10-72-72-c180.corp.yahoo.com [10.72.72.180]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8JF6m4S095768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Sep 2006 08:06:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=aj7tn2dYeTbOEwycWKMVg+I+9A2ozKc7jpQH1i7Y/A5FCqhrszlnOTvArUNIRCf4 Message-ID: <45100788.7010500@yahoo-inc.com> Date: Tue, 19 Sep 2006 08:06:48 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: zh-hakka References: <01dc01c6dae6$cb0ae560$6401a8c0@DGBP7M81> <450E45DF.79AD@xyzzy.claranet.de> <20060918103449.GB9546@nic.fr> <021301c6db26$c7d568d0$6401a8c0@DGBP7M81> <450EEE81.70603@yahoo-inc.com> <004701c6dbb2$1e6699e0$6401a8c0@DGBP7M81> In-Reply-To: <004701c6dbb2$1e6699e0$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Frank Ellermann , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org It occurs to me that we should add text in 4646bis forbidding the registration of those subtags that would make a grandfathered tag, if that tag is deprecated. Rather than regularizing "zh-hakka" (and friends), we ought to prevent conflicts with it so that it can rest in peace. Addison Doug Ewell wrote: > Addison Phillips wrote: > >> It's a coincidence, but one that is desirable. In other words, I think >> it would be a Bad Thing to deprecate some value in favor of a >> grandfathered tag in the post-RFC 4646 era. > > Of course it would. Nobody's proposing to do this in the future. We > are talking about the situation with "zh-hakka", which became the > Preferred-Value for "i-hak" (except we didn't call it that) back in the > RFC 1766 era. It's not going to be partitioned into language + variant > (unlike "en-boont") because we know the language is covered by ISO > 639-3. This situation could not happen again. > >> In fact, the rules explicitly allow a Preferred-Value to be a tag, if >> the thing being deprecated is a grandfathered item. In 4646bis, for >> example, it says: >> ... >> # For fields of type 'grandfathered' and 'redundant', a canonical >> mapping to a complete language tag. > > I did cite that. We know the P-V for deprecated tag "A" must be another > tag -- the question is whether tag "B" can be a grandfathered tag. And > the answer is, of course it can, as long as tag "B" replaced tag "A" > before the RFC 4646 era. That is exactly what happened with "zh-hakka". > > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > RFC 4645 * UTN #14 > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 11:08:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhCh-0003N0-GK; Tue, 19 Sep 2006 11:08:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhCg-0003Mr-N2 for ltru@ietf.org; Tue, 19 Sep 2006 11:08:06 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPhCf-0006mT-8g for ltru@ietf.org; Tue, 19 Sep 2006 11:08:06 -0400 Received: from [10.72.72.180] (snvvpn1-10-72-72-c180.corp.yahoo.com [10.72.72.180]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8JF7qPt095810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Sep 2006 08:07:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=ceLWoqbLsHKhruPysbg9CJxaIwJZN88gUVRYv/2TQnbRPeT51sZJc2ikZo7AskWK Message-ID: <451007C8.2000607@yahoo-inc.com> Date: Tue, 19 Sep 2006 08:07:52 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: RFC 4646 production "grandfathered" considered harmful References: <007c01c6dbf1$cad3d780$6401a8c0@DGBP7M81> In-Reply-To: <007c01c6dbf1$cad3d780$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Doug Ewell wrote: > Mark Davis wrote: > >> Although Frank has a point, I think my preferred approach would be to >> simply define but immediately deprecate subtags like lobjan -- that >> removes them from the grandfathered list. For the ABNF, we are then >> only left with the items that are syntactically ill-formed, which we >> could express with: >> >> grandfathered = "i-" irregularI >> / "sgn-" irregularSgn >> / irregularOther >> >> irregularI = "ami" / "bnn" / "default" / "enochian" / "hak" / >> "klingon" / "lux" / "mingo" / "navajo" / "pwn" / "tao" / "tay" / "tsu" >> irregularSgn= "BE-fr" / "BE-nl" / "CH-de" >> irregularOther = "en-GB-oed" >> >> We then have the smallest ABNF that (with the exception of duplicate >> singletons), describes the well-formed cases without letting anything >> else in. > > I think creating more deprecated-at-birth subtags is a terrible idea. As > you showed, it doesn't even simplify the ABNF -- you still have the > messy "irregularOther" production. It reduces the size of the list in > the ABNF, but increases the amount of trash in the Registry. > > The ABNF can't cover every possible syntactical tagging rule anyway; > consider en-b-bbb-a-aaa. > > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > RFC 4645 * UTN #14 > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 11:08:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhDE-00043m-Oy; Tue, 19 Sep 2006 11:08:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhDC-0003xW-VD for ltru@lists.ietf.org; Tue, 19 Sep 2006 11:08:38 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPhDA-0006pU-Mg for ltru@lists.ietf.org; Tue, 19 Sep 2006 11:08:38 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 1A0B326C218; Tue, 19 Sep 2006 17:08:36 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 1C48026C215; Tue, 19 Sep 2006 17:08:35 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 0FC0558ED1C; Tue, 19 Sep 2006 17:08:35 +0200 (CEST) Date: Tue, 19 Sep 2006 17:08:34 +0200 From: Stephane Bortzmeyer To: Addison Phillips Message-ID: <20060919150834.GA3281@nic.fr> References: <20060804165720.GA24037@sources.org> <44D4AC42.79E0@xyzzy.claranet.de> <20060830093000.GA31895@nic.fr> <44F6313D.2070000@yahoo-inc.com> <6.0.0.20.2.20060831201004.101ab8d0@localhost> <44F6EF0E.20602@yahoo-inc.com> <6.0.0.20.2.20060901024806.109a6d90@localhost> <30b660a20609161628t22ab3c4flc81ea92f40800a09@mail.gmail.com> <20060919121208.GA20171@nic.fr> <45100271.5090407@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45100271.5090407@yahoo-inc.com> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: ltru@lists.ietf.org Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Tue, Sep 19, 2006 at 07:45:05AM -0700, Addison Phillips wrote a message of 27 lines which said: > "Lxs" would be an extlang and "qu" would be a region. Yes, of course, my bug. Fixed, thanks. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 11:10:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhEn-0007Qg-Mh; Tue, 19 Sep 2006 11:10:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhEm-0007Qa-Ne for ltru@lists.ietf.org; Tue, 19 Sep 2006 11:10:16 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPhEl-0006xc-E8 for ltru@lists.ietf.org; Tue, 19 Sep 2006 11:10:16 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPhBm-0001iO-W7 for ltru@lists.ietf.org; Tue, 19 Sep 2006 17:07:11 +0200 Received: from pd9fba92d.dip0.t-ipconnect.de ([217.251.169.45]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 17:07:10 +0200 Received: from nobody by pd9fba92d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 17:07:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 19 Sep 2006 17:04:50 +0200 Organization: Lines: 17 Message-ID: <45100712.2C62@xyzzy.claranet.de> References: <008601c6dbf6$8238dc00$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba92d.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Re: zh-hakka X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: >> there's never a danger of A -> B -> C -> A, if A *_must_* >> point to something that has no further pointer. > I think we are again trying to legislate against the > unthinkable. [...] > There is no reasonable chance that ietf-languages will ever > make an older (sub)tag the Preferred-Value for a newer one. Not intentionally, but with a valid A -> B and a new subtag C deprecating B you get A -> B -> C, and a simple typo could twist this into A -> B -> A. Admittedly I like graph theory. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 11:29:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhX9-0006Hw-AQ; Tue, 19 Sep 2006 11:29:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhX8-0006Hi-5V for ltru@ietf.org; Tue, 19 Sep 2006 11:29:14 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPhX0-0001NR-PQ for ltru@ietf.org; Tue, 19 Sep 2006 11:29:14 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.628.4; Tue, 19 Sep 2006 08:29:06 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 08:29:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: UTF-8 Date: Tue, 19 Sep 2006 08:29:01 -0700 Message-ID: In-Reply-To: <6.0.0.20.2.20060919221647.09c4d170@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: UTF-8 Thread-Index: Acbb8Sn7062KA65uTtOT/BLtEWWLHwADmn3g From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 19 Sep 2006 15:29:05.0978 (UTC) FILETIME=[57EB31A0:01C6DC00] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org There's a prior question: what will the content of registry records contain? (We don't need an encoding that supports the entire UCS if we don't intend to have records using characters from that entire repertoire.) I don't recall if that's been discussed and resolved. I do support using an encoding that directly supports whatever characters we wish to allow in the registry without use of NCRs or other such escape mechanisms; and if we wish to allow any UCS character in the registry then I would support using UTF-8 as the encoding. Peter > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: Tuesday, September 19, 2006 6:18 AM > To: Peter Constable; LTRU Working Group > Subject: RE: [Ltru] Re: UTF-8 >=20 > [chair hat on] >=20 > Peter, with the observation below, do you want to say > you are in favor of moving to UTF-8, or against, or > did you write that strictly as an observation only? >=20 > Regards, Martin. >=20 > At 16:04 06/09/18, Peter Constable wrote: > >> From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > > > > > >> Agreed. In my point of view, the pain of Bokm&#$!@*l outweights > >> a lot of things. The main benefit is that native people can > >> easily check that things are correct, which they won't do > >> if we show them just a number. > > > >There's lots of software that will interpret an NCR in an HTML, XML or HTML > >file and display it to the user as the actual character in the UCS for > >which it is a reference. I don't think there is any software that will do > >this for the file located at > >http://www.iana.org/assignments/language-subtag-registry. > > > > > > > > > >Peter Constable >=20 >=20 >=20 > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 11:46:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhnJ-0003Lq-IO; Tue, 19 Sep 2006 11:45:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhnJ-0003Lk-1T for ltru@ietf.org; Tue, 19 Sep 2006 11:45:57 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPhnE-0003T1-I8 for ltru@ietf.org; Tue, 19 Sep 2006 11:45:57 -0400 Received: from [10.72.72.180] (snvvpn1-10-72-72-c180.corp.yahoo.com [10.72.72.180]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8JFjmv9094832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Sep 2006 08:45:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=2jWbKZHcZdo1tpPg/1l9iegHd8wvwNpLKgvMPUqlSwrIOEuk4+N43ql3gKnJDt4E Message-ID: <451010AB.3090406@yahoo-inc.com> Date: Tue, 19 Sep 2006 08:45:47 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] Re: UTF-8 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Descriptions and comments both allow the full range of Unicode today. Doug has noted some number of items (perhaps a dozen) that use non-ASCII (mostly Latin-script) letters or symbols. There is no check for the range of characters permitted, nor (in our discussion in draft-registry days) should there be. I think that limiting the repertoire to anything less than the full range of the UCS would prove problematic anyway. And while I don't see a pressing need to identify languages in their native form, some people might find it offensive if it were banned outright. Similarly, some might find comments clearer if they contained some native description. I don't know. What I do know is that I think that the only limitation that could reasonably be made that would be non-arbitrary would be a limitation to ASCII. And I, personally, will not support any encodings except those two for encoding the registry: either US-ASCII or UTF-8. Addison Peter Constable wrote: > There's a prior question: what will the content of registry records > contain? (We don't need an encoding that supports the entire UCS if we > don't intend to have records using characters from that entire > repertoire.) I don't recall if that's been discussed and resolved. > > I do support using an encoding that directly supports whatever > characters we wish to allow in the registry without use of NCRs or other > such escape mechanisms; and if we wish to allow any UCS character in the > registry then I would support using UTF-8 as the encoding. > > > Peter > > > >> -----Original Message----- >> From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] >> Sent: Tuesday, September 19, 2006 6:18 AM >> To: Peter Constable; LTRU Working Group >> Subject: RE: [Ltru] Re: UTF-8 >> >> [chair hat on] >> >> Peter, with the observation below, do you want to say >> you are in favor of moving to UTF-8, or against, or >> did you write that strictly as an observation only? >> >> Regards, Martin. >> >> At 16:04 06/09/18, Peter Constable wrote: >>>> From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] >>> >>>> Agreed. In my point of view, the pain of Bokm&#$!@*l outweights >>>> a lot of things. The main benefit is that native people can >>>> easily check that things are correct, which they won't do >>>> if we show them just a number. >>> There's lots of software that will interpret an NCR in an HTML, XML > or HTML >>> file and display it to the user as the actual character in the UCS > for >>> which it is a reference. I don't think there is any software that > will do >>> this for the file located at >>> http://www.iana.org/assignments/language-subtag-registry. >>> >>> >>> >>> >>> Peter Constable >> >> >> #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University >> #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 12:14:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPiEr-0001Eg-VT; Tue, 19 Sep 2006 12:14:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPiEr-0001EM-4V for ltru@ietf.org; Tue, 19 Sep 2006 12:14:25 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPiEm-0006yx-P1 for ltru@ietf.org; Tue, 19 Sep 2006 12:14:25 -0400 Received: from [10.72.72.180] (snvvpn1-10-72-72-c180.corp.yahoo.com [10.72.72.180]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8JGEFxR098558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Sep 2006 09:14:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=JnJKeAhl4iHb389sb3N9795k95vJ1TI2h8FXvpzV883sg/UOpcKCEpp9EbqREbv0 Message-ID: <45101757.9020807@yahoo-inc.com> Date: Tue, 19 Sep 2006 09:14:15 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "'LTRU Working Group'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ltru] split section 3.1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org To address the various comments on the length of Section 3.1, I have created an experimental version of draft-01 and posted it on my website. I split the section into three sections: File Format, Record Definitions, and Field Requirements. That last is split up by field type. Some text rearrangement was necessary to make this work and a little bit of editing was done. The last section needs an introductory paragraph (yes, Martin, yes, I know :-) ) and a bit more tugging is necessary. However... I think it important to get a consensus that such a massive edit is called for (just to split the darned thing up a bit). I *personally* feel that this is something that should be left alone: we didn't do it in the 4646 era, why now? File are at: http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-01alpha.txt http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-01alpha.html http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-01alpha.xml Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 12:16:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPiGk-0001nZ-Vt; Tue, 19 Sep 2006 12:16:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPiGj-0001mh-SU for ltru@ietf.org; Tue, 19 Sep 2006 12:16:21 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPiGi-0007PX-FO for ltru@ietf.org; Tue, 19 Sep 2006 12:16:21 -0400 Received: from [10.72.72.180] (snvvpn1-10-72-72-c180.corp.yahoo.com [10.72.72.180]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8JGGJD6098631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Sep 2006 09:16:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=mtHqT9OnqGfBt5hVgboGwDWq9m2oiQRVTsml1YYT/9vgQnuMg1sLJRmRAP+bSZwY Message-ID: <451017D3.9080701@yahoo-inc.com> Date: Tue, 19 Sep 2006 09:16:19 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] split section 3.1 References: <45101757.9020807@yahoo-inc.com> In-Reply-To: <45101757.9020807@yahoo-inc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Oh... and (pre-)draft-01 with the ABNF change is posted too... http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-01.txt http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-01.html http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-01.xml Addison Phillips wrote: > To address the various comments on the length of Section 3.1, I have > created an experimental version of draft-01 and posted it on my website. > > I split the section into three sections: File Format, Record > Definitions, and Field Requirements. That last is split up by field > type. Some text rearrangement was necessary to make this work and a > little bit of editing was done. The last section needs an introductory > paragraph (yes, Martin, yes, I know :-) ) and a bit more tugging is > necessary. > > However... I think it important to get a consensus that such a massive > edit is called for (just to split the darned thing up a bit). I > *personally* feel that this is something that should be left alone: we > didn't do it in the 4646 era, why now? > > File are at: > > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-01alpha.txt > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-01alpha.html > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-01alpha.xml > > Addison > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 19 20:42:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPqAB-0001NY-Gf; Tue, 19 Sep 2006 20:42:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPqAA-0001MX-0X for ltru@ietf.org; Tue, 19 Sep 2006 20:42:06 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPqA8-0000rF-MM for ltru@ietf.org; Tue, 19 Sep 2006 20:42:05 -0400 Received: from terminus.local (dhcp-37-248.icann.org [192.0.37.248]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id k8K0gUuk018692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 19 Sep 2006 17:42:30 -0700 Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 19 Sep 2006 17:41:51 -0700 X-PGP-Universal: processed; by terminus.local on Tue, 19 Sep 2006 17:41:51 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> To: ltru@ietf.org From: David Conrad Date: Tue, 19 Sep 2006 17:41:49 -0700 X-Mailer: Apple Mail (2.752.2) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] IANA XML registries X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, Stephane Bortzmeyer wrote: >> Any news about the supposed plan to move all IANA registries to XML? > > No idea. Do you mind if I ping the IANA about that? Yes, IANA is undertaking to convert all our registries over to XML. We'll be doing this in an incremental fashion of course, starting with a few of the simpler registries, getting feedback from people, revising and doing more registries, getting feedback, etc. until everything is converted over. Part of this project will also be to generate "legacy" registries from the XML in formats that are as close to what exists now as we can easily manage (in an undoubtedly vain attempt to try to limit the screams of outrage from the poor souls who have hacked software to deal with the existing registries). We anticipate having the first set of registries (and various backend systems we use internally) done by sometime around the beginning of 2007. A more formal announcement of this effort will probably be made at the San Diego IETF. I'm happy to answer any questions folk might have... Regards, -drc General Manager, IANA _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 00:32:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPtkv-0000sJ-Qp; Wed, 20 Sep 2006 00:32:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPtku-0000sE-Kz for ltru@ietf.org; Wed, 20 Sep 2006 00:32:16 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPtks-00083g-Aq for ltru@ietf.org; Wed, 20 Sep 2006 00:32:16 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060920043213.QPEL12100.mta13.adelphia.net@DGBP7M81>; Wed, 20 Sep 2006 00:32:13 -0400 Message-ID: <004301c6dc6d$bebab190$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <008601c6dbf6$8238dc00$6401a8c0@DGBP7M81> <451006C2.60603@yahoo-inc.com> Subject: Re: [Ltru] Re: zh-hakka Date: Tue, 19 Sep 2006 21:32:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Frank Ellermann X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> There is no reasonable chance that ietf-languages will ever make an >> older (sub)tag the Preferred-Value for a newer one. > > Not intentionally, but with a valid A -> B and a new subtag C > deprecating B you get A -> B -> C, and a simple typo could twist this > into A -> B -> A. Admittedly I like graph theory. Typos in any of the the normative parts of the Registry could cause any number of problems. That's why some of us are watching diligently every time IANA releases a new version, and scrutinizing the registration forms with a magnifying glass before they are submitted to IANA. IANA is not perfect. Already since the "RFC 3066bis" era began, they have released one with a duplicated record, one with a missing Type field, and one with a multi-line Comments field that was missing the critical leading spaces on the second line. Because we are watching carefully for typos such as these, they were fixed quickly and the number of users that were affected is most likely zero. Addison Phillips wrote: > That might not turn out to be true. For example, sometimes countries > merge together. That's a good point. I take back the overly broad statement. Let's consider the case of countries merging. Since Serbia and Montenegro has been such a commonly cited example in LTRU, let's stay with it. In the next few weeks, or months or something, ISO 3166/MA will decide on new alpha-2 code elements for Serbia and for Montenegro, now that they have agreed to break up. I don't have any inside knowledge on what the code elements will be, but two widely reported possibilities are SP and ME, so let's assume that for now. Naturally, these code elements will be transformed into RFC 4646 region subtags, but the existing subtag CS will *not* be given a Preferred-Value of either SP or ME. If the two countries -- hypothetically speaking -- should decide to reunite at a later date, the subtags SP and ME would probably be assigned a Preferred-Value of CS, but there would be no circularity problem. I'd be interested if somebody could come up with a plausible scenario that would result in circular P-V assignments. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 00:45:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPtx8-0001pW-EN; Wed, 20 Sep 2006 00:44:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPtx7-0001mY-8Z for ltru@ietf.org; Wed, 20 Sep 2006 00:44:53 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPtx6-0001DM-1A for ltru@ietf.org; Wed, 20 Sep 2006 00:44:53 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060920044451.ZTXX14728.mta10.adelphia.net@DGBP7M81> for ; Wed, 20 Sep 2006 00:44:51 -0400 Message-ID: <004501c6dc6f$828124a0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 19 Sep 2006 21:44:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ltru] Re: UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > There's a prior question: what will the content of registry records > contain? (We don't need an encoding that supports the entire UCS if we > don't intend to have records using characters from that entire > repertoire.) I don't recall if that's been discussed and resolved. The existing RFC 4646 Registry already contains instances of 11 different non-ASCII characters, including 3 that are not in Latin-1. The current set of 7,600 reference names in ISO/FDIS 639-3 contains almost 500 Latin-1 characters, all of which will end up in the Registry. (They have to; there are some language names in 639-3 that are differentiated only by an accent.) Clearly the Registry needs an encoding that supports characters beyond ASCII or even Latin-1. We already have one: the much-grumbled-about hex NCR's. UTF-8 would be another. While we could limit the Registry to a subset of the UCS, such as MES-2 -- or MES-1, if we were willing to go through the intense pain of removing "Ethiopic (Geʻez)" -- I don't see what advantage it would bring. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 00:58:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPuAG-0005Mg-Q2; Wed, 20 Sep 2006 00:58:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPuAF-0005MY-9P for ltru@ietf.org; Wed, 20 Sep 2006 00:58:27 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPuAE-0002Rk-1o for ltru@ietf.org; Wed, 20 Sep 2006 00:58:27 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060920045825.YDRZ25133.mta11.adelphia.net@DGBP7M81> for ; Wed, 20 Sep 2006 00:58:25 -0400 Message-ID: <004d01c6dc71$67a3c8c0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 19 Sep 2006 21:58:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Ltru] Errors in prototype 4646bis Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org There are two problems in the prototype RFC 4646bis Registry I posted a few days ago. The first problem is an extra trailing space-and-asterisk in 13 Description fields, for the language subtag records that have an extlang with the same name. The group agreed (I think) not to change any existing names, although that means we will have (for example) a language subtag called "Konkani" and "Konkani (macrolanguage)" and an extlang also called "Konkani". I marked these 13 cases with an asterisk so they could be easily removed (or retained) after the decision was made, and forgot to rip out the asterisks before posting. The second problem runs a bit deeper. ISO 639-2 just added a new code element "zza" with six names, one of which is "Dimli". ISO 639-3 has a code element "diq" with the name "Dimli". If both of these are admitted into the Registry, there will be two subtags of the *same type* with the same Description. No matter what anyone says about retaining the "official" ISO names, that is not a tolerable situation. Peter indicated on ietf-languages that the ISO 639 JAC would decide what to do about this in due course, but until they do, I need to know what to do with the Registry. I'll post an updated version when a decision is reached. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 01:01:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPuCp-0007NY-DR; Wed, 20 Sep 2006 01:01:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPuCo-0007NJ-CC for ltru@ietf.org; Wed, 20 Sep 2006 01:01:06 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPuCn-0002qU-5M for ltru@ietf.org; Wed, 20 Sep 2006 01:01:06 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060920050104.DPEE17675.mta9.adelphia.net@DGBP7M81> for ; Wed, 20 Sep 2006 01:01:04 -0400 Message-ID: <005301c6dc71$c666d140$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 19 Sep 2006 22:01:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ltru] Re: RFC 4646 production "grandfathered" considered harmful X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I wrote: > The ABNF can't cover every possible syntactical tagging rule anyway; > consider en-b-bbb-a-aaa. That was a typo; the example I gave is well-formed. I should have written "en-a-bbb-a-aaa". -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 01:36:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPukb-0007i6-8g; Wed, 20 Sep 2006 01:36:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPukZ-0007gZ-BR for ltru@ietf.org; Wed, 20 Sep 2006 01:35:59 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPugb-0007UH-Kd for ltru@ietf.org; Wed, 20 Sep 2006 01:31:54 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060920053148.UNZ14728.mta10.adelphia.net@DGBP7M81>; Wed, 20 Sep 2006 01:31:48 -0400 Message-ID: <005701c6dc76$11d65a70$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 19 Sep 2006 22:31:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: IANA XML registries X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org David Conrad wrote: > Yes, IANA is undertaking to convert all our registries over to XML. > We'll be doing this in an incremental fashion of course, starting with > a few of the simpler registries, getting feedback from people, > revising and doing more registries, getting feedback, etc. until > everything is converted over. Part of this project will also be to > generate "legacy" registries from the XML in formats that are as close > to what exists now as we can easily manage (in an undoubtedly vain > attempt to try to limit the screams of outrage from the poor souls who > have hacked software to deal with the existing registries). Now that we know this, shall we bite the bullet and do this ourselves? -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 02:50:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPvuI-00017c-U5; Wed, 20 Sep 2006 02:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPvuH-00017X-E3 for ltru@lists.ietf.org; Wed, 20 Sep 2006 02:50:05 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPvuF-0005M9-0S for ltru@lists.ietf.org; Wed, 20 Sep 2006 02:50:05 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPvtv-0004OW-HX for ltru@lists.ietf.org; Wed, 20 Sep 2006 08:49:43 +0200 Received: from pd9fba8f1.dip0.t-ipconnect.de ([217.251.168.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Sep 2006 08:49:43 +0200 Received: from nobody by pd9fba8f1.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Sep 2006 08:49:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 20 Sep 2006 08:48:00 +0200 Organization: Lines: 32 Message-ID: <4510E420.6010@xyzzy.claranet.de> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8f1.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [Ltru] Re: IANA XML registries X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org David Conrad wrote: > Part of this project will also be to generate "legacy" > registries from the XML in formats that are as close to what > exists now as we can easily manage (in an undoubtedly > vain attempt to try to limit the screams of outrage from the > poor souls who have hacked software to deal with the existing > registries). That's rather important, e.g. it's not yet mentioned in a new submitted five days ago. I saw no discussion about it on the XML-dir list. It can affect any charset registry cleanup attempts (and Ira's tool donated to IANA), and of course it's also interesting for any modifications of the language subtag registry format. With Stephane's tip "Apricot" and Google I found a note from you in March about "eIANA", that sounded perfectly harmless, new Web site, new forms, faster, better, enjoy. Google didn't find what you said in January, but apparently half of the IAB should have known that that's coming, and not a minor issue. Maybe they ignored it at this time because it was before the renewal or SLA or whatever it was (IANAL), but forgetting it was "sub-optimal" (I hope that word has the same connotations in English as in German). Thanks for info Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 03:15:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPwIN-0001cW-Mj; Wed, 20 Sep 2006 03:14:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPwIM-0001XO-Dl for ltru@lists.ietf.org; Wed, 20 Sep 2006 03:14:58 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPwIL-0003F0-4F for ltru@lists.ietf.org; Wed, 20 Sep 2006 03:14:58 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPwIE-00010V-0D for ltru@lists.ietf.org; Wed, 20 Sep 2006 09:14:50 +0200 Received: from pd9fba8f1.dip0.t-ipconnect.de ([217.251.168.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Sep 2006 09:14:49 +0200 Received: from nobody by pd9fba8f1.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Sep 2006 09:14:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 20 Sep 2006 09:14:03 +0200 Organization: Lines: 22 Message-ID: <4510EA3B.33DF@xyzzy.claranet.de> References: <008601c6dbf6$8238dc00$6401a8c0@DGBP7M81> <451006C2.60603@yahoo-inc.com> <004301c6dc6d$bebab190$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8f1.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] Re: zh-hakka X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > That's why some of us are watching diligently every time IANA > releases a new version, and scrutinizing the registration > forms with a magnifying glass before they are submitted to > IANA. My (now two) magnifying glasses don't catch unintended cycles. With a rule "pointers only to non-deprecated (sub)tags" they could easily catch such typos. > I'd be interested if somebody could come up with a plausible > scenario that would result in circular P-V assignments. MY reverting to BU, or C? reverting to ZR, that might not work as expected with 4646 rules (too lazy to check). With Martin's proposal it works, the BU -> MY pointer would be replaced by a BU -> BU pointer, and the fine print would say that this should be reduced to no pointer at all. Adding MY -> BU as expected. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 03:15:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPwJL-00024k-3A; Wed, 20 Sep 2006 03:15:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPwJK-00024f-D8 for ltru@lists.ietf.org; Wed, 20 Sep 2006 03:15:58 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPwJJ-0003Lq-4N for ltru@lists.ietf.org; Wed, 20 Sep 2006 03:15:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 67CBD26C1B4; Wed, 20 Sep 2006 09:15:46 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 84A6326C199; Wed, 20 Sep 2006 09:15:45 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 6C8D858ED70; Wed, 20 Sep 2006 09:15:45 +0200 (CEST) Date: Wed, 20 Sep 2006 09:15:45 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20060920071545.GA8794@nic.fr> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4510E420.6010@xyzzy.claranet.de> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: IANA XML registries X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Wed, Sep 20, 2006 at 08:48:00AM +0200, Frank Ellermann wrote a message of 32 lines which said: > I found a note from you in March about "eIANA", that sounded > perfectly harmless, eIANA has nothing to do with XML. It is a Web interface for TLD managers to ask IANA and the DoC about the changes they request in the root zone file of the DNS. No relationship with the "ordinary" registry business of IANA (the one we depend on) and no relationship with LTRU. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 03:17:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPwKf-0002rS-51; Wed, 20 Sep 2006 03:17:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPwKd-0002rN-N3 for ltru@lists.ietf.org; Wed, 20 Sep 2006 03:17:19 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPwKc-0003Wl-Ec for ltru@lists.ietf.org; Wed, 20 Sep 2006 03:17:19 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 1446D26C197; Wed, 20 Sep 2006 09:17:18 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 5496626C159; Wed, 20 Sep 2006 09:17:17 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 430FC58ED1C; Wed, 20 Sep 2006 09:17:17 +0200 (CEST) Date: Wed, 20 Sep 2006 09:17:17 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20060920071717.GB8794@nic.fr> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4510E420.6010@xyzzy.claranet.de> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@lists.ietf.org Subject: [Ltru] Re: IANA XML registries X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Wed, Sep 20, 2006 at 08:48:00AM +0200, Frank Ellermann wrote a message of 32 lines which said: > but apparently half of the IAB should have known that that's coming, > and not a minor issue. I want to repeat that RFC 4646 is an exception, not the rule. Most of the RFCs which instruct IANA to create a registry leave the details completely open and, unlike RFC 4646, never specify a format for the registry. IMHO, it means IANA is quite free to change the master format. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 03:33:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPwaC-00058Y-Kp; Wed, 20 Sep 2006 03:33:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPwaB-00058S-0z for ltru@lists.ietf.org; Wed, 20 Sep 2006 03:33:23 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPwa9-00081S-Nm for ltru@lists.ietf.org; Wed, 20 Sep 2006 03:33:23 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPwZp-0005iW-78 for ltru@lists.ietf.org; Wed, 20 Sep 2006 09:33:06 +0200 Received: from pd9fba8f1.dip0.t-ipconnect.de ([217.251.168.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Sep 2006 09:33:01 +0200 Received: from nobody by pd9fba8f1.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Sep 2006 09:33:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 20 Sep 2006 09:31:41 +0200 Organization: Lines: 33 Message-ID: <4510EE5D.389E@xyzzy.claranet.de> References: <45101757.9020807@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8f1.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [Ltru] Re: split section 3.1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I split the section into three sections: File Format, Record > Definitions, and Field Requirements. Makes sense. > That last is split up by field type. I'm not sure about using
3.1.3.x, it's not very nice, and you kept the default

limit in the ToC, so it doesn't show up in the ToC. > I think it important to get a consensus that such a massive > edit is called for (just to split the darned thing up a bit). You could pick a less massive split (3.1.1 isn't strictly necessary), keeping the old layout as is. 3.1 (Intro) up to "Gregorian Date" (more or less record-jar) 3.1.1 Required Records (starting at "The first record" etc.) 3.1.2 Optional Records (starting at "Each record MAY") That would be a minimal edit, but still splits 3.1 in three logical parts. > we didn't do it in the 4646 era, why now? In the 4646 era we were busy to convince you that numbers are better than bullets when talking about the details of 3.1 Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 04:17:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPxGZ-0003Xj-Ph; Wed, 20 Sep 2006 04:17:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPxGY-0003SB-NP for ltru@lists.ietf.org; Wed, 20 Sep 2006 04:17:10 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPxGU-0008OS-CL for ltru@lists.ietf.org; Wed, 20 Sep 2006 04:17:10 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPxG9-0000U9-CM for ltru@lists.ietf.org; Wed, 20 Sep 2006 10:16:45 +0200 Received: from pd9fba8f1.dip0.t-ipconnect.de ([217.251.168.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Sep 2006 10:16:45 +0200 Received: from nobody by pd9fba8f1.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Sep 2006 10:16:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 20 Sep 2006 10:14:27 +0200 Organization: Lines: 26 Message-ID: <4510F863.1C21@xyzzy.claranet.de> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> <20060920071545.GA8794@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8f1.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Ltru] Re: IANA XML registries X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > eIANA has nothing to do with XML. It is a Web interface for > TLD managers to ask IANA and the DoC about the changes they > request in the root zone file of the DNS. While they're at it whois.iana.org should be integrated into WDPRS, there are many bogus whois servers and broken URLs in their data. Or at least that was the case some months ago. > No relationship with the "ordinary" registry business of IANA Registry is registry, when I read "better forms" I thought it could be an improved version of: http://www.iana.org/protocols/forms.htm > (the one we depend on) and no relationship with LTRU. From my POV it's related, I'm here because I didn't like what the pre-LTRU draft said about country codes, and that's because of my whois client with TLDs including ccTLDs. "Ask IANA" was about the first thing it got right (after "ask abuse.net"). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 04:41:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPxeJ-0000xh-7p; Wed, 20 Sep 2006 04:41:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPxeI-0000uZ-24 for ltru@lists.ietf.org; Wed, 20 Sep 2006 04:41:42 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPxeG-0005fm-Nh for ltru@lists.ietf.org; Wed, 20 Sep 2006 04:41:42 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPxdx-0005vR-6A for ltru@lists.ietf.org; Wed, 20 Sep 2006 10:41:21 +0200 Received: from pd9fba8f1.dip0.t-ipconnect.de ([217.251.168.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Sep 2006 10:41:21 +0200 Received: from nobody by pd9fba8f1.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Sep 2006 10:41:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 20 Sep 2006 10:40:19 +0200 Organization: Lines: 23 Message-ID: <4510FE73.110A@xyzzy.claranet.de> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> <20060920071717.GB8794@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8f1.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Ltru] Re: IANA XML registries X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > Most of the RFCs which instruct IANA to create a registry > leave the details completely open and, unlike RFC 4646, > never specify a format for the registry. The _intended_ format of RFC 3864 is apparently like what you find in RFC 4021, the published registry in... http://www.iana.org/assignments/message-headers/perm-headers.html ...is rather minimalistic. > IMHO, it means IANA is quite free to change the master format For stuff that's in essence a collection of ":" fields in registration templates (= a "record" of record-jar) XML is not the ideal choice. Admittedly for the few registries I care about XML would be better than the status quo. Minus LTRU, that's fine. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 08:35:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ1IK-00051B-Uo; Wed, 20 Sep 2006 08:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ1IK-000515-61 for ltru@ietf.org; Wed, 20 Sep 2006 08:35:16 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ1II-00082r-W1 for ltru@ietf.org; Wed, 20 Sep 2006 08:35:16 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GQ1II-0007EX-Jd; Wed, 20 Sep 2006 08:35:14 -0400 Date: Wed, 20 Sep 2006 08:35:14 -0400 To: Doug Ewell Message-ID: <20060920123514.GA15905@ccil.org> References: <008601c6dbf6$8238dc00$6401a8c0@DGBP7M81> <451006C2.60603@yahoo-inc.com> <004301c6dc6d$bebab190$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004301c6dc6d$bebab190$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org Subject: [Ltru] Region subtag changes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > I'd be interested if somebody could come up with a plausible scenario > that would result in circular P-V assignments. What about a country reverting to an earlier name? We have two historical examples I can think of offhand, Central African Republic -> Central African Empire -> Central African Republic (which probably didn't affect the code) and Dem. Rep. of Congo -> Zaire -> Dem. Rep. of Congo (which did, fortunately before Date A). We might have another someday in Burma -> Myanmar -> Burma, since the dissidents (I believe this is correct) object to the process by which the (Latin-script) name of the country was changed. We already have BU deprecated in favor of MM; if the name is changed back and the old code is revived, we might end up with MM deprecated in favor of BU. -- Si hoc legere scis, nimium eruditionis habes. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 09:06:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ1m8-0004ZE-0W; Wed, 20 Sep 2006 09:06:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ1m6-0004Yy-Um for ltru@ietf.org; Wed, 20 Sep 2006 09:06:02 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ1m5-0003Wt-Nf for ltru@ietf.org; Wed, 20 Sep 2006 09:06:02 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060920130556.KTUL14728.mta10.adelphia.net@DGBP7M81> for ; Wed, 20 Sep 2006 09:05:56 -0400 Message-ID: <008101c6dcb5$82dfbc90$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Wed, 20 Sep 2006 06:05:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ltru] Re: split section 3.1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> we didn't do it in the 4646 era, why now? > > In the 4646 era we were busy to convince you that numbers are better > than bullets when talking about the details of 3.1 I suggested splitting Section 3.1 after making several on-list references to something being in "Section 3.1" and feeling like I was saying, "it's right there in 'War and Peace,' go look it up." I like the new organization. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 09:14:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ1uQ-0001aO-3D; Wed, 20 Sep 2006 09:14:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ1uO-0001Zn-Fr for ltru@ietf.org; Wed, 20 Sep 2006 09:14:36 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ1uN-0004P1-8Q for ltru@ietf.org; Wed, 20 Sep 2006 09:14:36 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060920131434.LKAA14728.mta10.adelphia.net@DGBP7M81>; Wed, 20 Sep 2006 09:14:34 -0400 Message-ID: <008501c6dcb6$b7b81150$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <008601c6dbf6$8238dc00$6401a8c0@DGBP7M81> <451006C2.60603@yahoo-inc.com> <004301c6dc6d$bebab190$6401a8c0@DGBP7M81> <20060920123514.GA15905@ccil.org> Date: Wed, 20 Sep 2006 06:14:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: Region subtag changes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > We might have another someday in Burma -> Myanmar -> Burma, since the > dissidents (I believe this is correct) object to the process by which > the (Latin-script) name of the country was changed. We already have > BU deprecated in favor of MM; if the name is changed back and the old > code is revived, we might end up with MM deprecated in favor of BU. That could only happen if we had a provision to un-deprecate a record, which I don't think we do. It might not hurt to add a sentence to (what is now) Section 3.1.3.3 to state that deprecation is forever, assuming we want that. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 09:29:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ28K-0005D1-EM; Wed, 20 Sep 2006 09:29:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ28J-0005AA-SY for ltru@ietf.org; Wed, 20 Sep 2006 09:28:59 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ28I-0006Ic-LW for ltru@ietf.org; Wed, 20 Sep 2006 09:28:59 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GQ28I-0001Sf-Cf; Wed, 20 Sep 2006 09:28:58 -0400 Date: Wed, 20 Sep 2006 09:28:58 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Region subtag changes Message-ID: <20060920132858.GD15905@ccil.org> References: <008601c6dbf6$8238dc00$6401a8c0@DGBP7M81> <451006C2.60603@yahoo-inc.com> <004301c6dc6d$bebab190$6401a8c0@DGBP7M81> <20060920123514.GA15905@ccil.org> <008501c6dcb6$b7b81150$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008501c6dcb6$b7b81150$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > >We might have another someday in Burma -> Myanmar -> Burma, since the > >dissidents (I believe this is correct) object to the process by which > >the (Latin-script) name of the country was changed. We already have > >BU deprecated in favor of MM; if the name is changed back and the old > >code is revived, we might end up with MM deprecated in favor of BU. > > That could only happen if we had a provision to un-deprecate a record, > which I don't think we do. In that case, I guess we'd have to go for the UNSD numeric code, namely 104. > It might not hurt to add a sentence to (what is now) Section 3.1.3.3 to > state that deprecation is forever, assuming we want that. Good idea. -- John Cowan http://www.ccil.org/~cowan One time I called in to the central system and started working on a big thick 'sed' and 'awk' heavy duty data bashing script. One of the geologists came by, looked over my shoulder and said 'Oh, that happens to me too. Try hanging up and phoning in again.' --Beverly Erlebacher _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 09:42:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2L8-0006cv-Bu; Wed, 20 Sep 2006 09:42:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2L7-0006cm-7x for ltru@ietf.org; Wed, 20 Sep 2006 09:42:13 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ2L4-0007jl-U2 for ltru@ietf.org; Wed, 20 Sep 2006 09:42:13 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060920134210.CVGP12100.mta13.adelphia.net@DGBP7M81>; Wed, 20 Sep 2006 09:42:10 -0400 Message-ID: <009101c6dcba$92663f40$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <008601c6dbf6$8238dc00$6401a8c0@DGBP7M81> <451006C2.60603@yahoo-inc.com> <004301c6dc6d$bebab190$6401a8c0@DGBP7M81> <20060920123514.GA15905@ccil.org> <008501c6dcb6$b7b81150$6401a8c0@DGBP7M81> <20060920132858.GD15905@ccil.org> Subject: Re: [Ltru] Re: Region subtag changes Date: Wed, 20 Sep 2006 06:42:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >>> ... We already have BU deprecated in favor of MM; if the name is >>> changed back and the old code is revived, we might end up with MM >>> deprecated in favor of BU. >> >> That could only happen if we had a provision to un-deprecate a >> record, which I don't think we do. > > In that case, I guess we'd have to go for the UNSD numeric code, > namely 104. Would we do that, or would we simply add a Description field for the new name? See the "Burkina Faso" example in Section 3.4 (although that refers to changing a Description, something that is now discouraged). This assumes that the entity in question remains the same, as judged by its UN code element, and only the name has changed. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 11:18:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ3qZ-0002yd-Ua; Wed, 20 Sep 2006 11:18:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ3qY-0002wZ-EO for ltru@lists.ietf.org; Wed, 20 Sep 2006 11:18:46 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ3qX-0005y1-3d for ltru@lists.ietf.org; Wed, 20 Sep 2006 11:18:46 -0400 Received: from terminus.local (c-24-130-17-72.hsd1.ca.comcast.net [24.130.17.72]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id k8KFJ8F7019965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Sep 2006 08:19:09 -0700 Received: from [127.0.0.1] by terminus.local (PGP Universal service); Wed, 20 Sep 2006 08:18:27 -0700 X-PGP-Universal: processed; by terminus.local on Wed, 20 Sep 2006 08:18:27 -0700 In-Reply-To: <4510E420.6010@xyzzy.claranet.de> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: David Conrad Subject: Re: [Ltru] Re: IANA XML registries Date: Wed, 20 Sep 2006 08:18:23 -0700 To: Frank Ellermann X-Mailer: Apple Mail (2.752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank, On Sep 19, 2006, at 11:48 PM, Frank Ellermann wrote: > That's rather important, e.g. it's not yet mentioned in a new > submitted five > days ago. I saw no discussion about it on the XML-dir list. To clarify, the XML-ization of IANA registries is an _internal_ effort, primarily aimed at allowing us to simplify/automate registry creation and modification. We will take what efforts we can to insure there is no significant change to the "legacy" registries. We will _also_ publish the initial set of XML-ized registries (at different URLs of course) and request comments. Assuming the initial forays into XML-ization are deemed acceptable, we'll publish more. If not (hey, it could happen), we'll not publish more (but we'll still use the XML registries internally). > With Stephane's tip "Apricot" and Google I found a note from > you in March about "eIANA", that sounded perfectly harmless, > new Web site, new forms, faster, better, enjoy. As Stephane indicated, eIANA is completely unrelated to the registry XML-ization effort. > Google didn't > find what you said in January, but apparently half of the IAB > should have known that that's coming, and not a minor issue. Actually, I believe it is a minor issue (at least from an external perspective). Rgds, -drc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 11:29:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ40e-0002qf-6h; Wed, 20 Sep 2006 11:29:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ40d-0002qT-Av for ltru@lists.ietf.org; Wed, 20 Sep 2006 11:29:11 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ40X-0007QF-QN for ltru@lists.ietf.org; Wed, 20 Sep 2006 11:29:11 -0400 Received: from terminus.local (c-24-130-17-72.hsd1.ca.comcast.net [24.130.17.72]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id k8KFTZwW019977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Sep 2006 08:29:36 -0700 Received: from [127.0.0.1] by terminus.local (PGP Universal service); Wed, 20 Sep 2006 08:28:54 -0700 X-PGP-Universal: processed; by terminus.local on Wed, 20 Sep 2006 08:28:54 -0700 In-Reply-To: <4510F863.1C21@xyzzy.claranet.de> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> <20060920071545.GA8794@nic.fr> <4510F863.1C21@xyzzy.claranet.de> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: David Conrad Subject: Re: [Ltru] Re: IANA XML registries Date: Wed, 20 Sep 2006 08:28:51 -0700 To: Frank Ellermann X-Mailer: Apple Mail (2.752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank, On Sep 20, 2006, at 1:14 AM, Frank Ellermann wrote: > While they're at it whois.iana.org should be integrated into > WDPRS, there are many bogus whois servers and broken URLs in > their data. Or at least that was the case some months ago. IANA has another project to replace the current whois server system we use. This project will, of course, be related to the deployment of eIANA. However, in the meantime, I will look into linking into WDPRS. >> No relationship with the "ordinary" registry business of IANA > > Registry is registry, when I read "better forms" I thought it > could be an improved version of: > > http://www.iana.org/protocols/forms.htm No, that's yet another IANA project (as Stephane said in a previous message, we're pretty busy :-)) but it is somewhat related in the sense that one of the reasons for XMLization of the registries is to normalize how the data is represented internally so we can more easily automate forms for registry modification requests. Rgds, -drc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 12:02:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ4WX-00015N-2F; Wed, 20 Sep 2006 12:02:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ4WV-0000zR-Un for ltru@ietf.org; Wed, 20 Sep 2006 12:02:08 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ4WU-0005QF-J0 for ltru@ietf.org; Wed, 20 Sep 2006 12:02:07 -0400 Received: from terminus.local (c-24-130-17-72.hsd1.ca.comcast.net [24.130.17.72]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id k8KG2OxB020062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Sep 2006 09:02:26 -0700 Received: from [127.0.0.1] by terminus.local (PGP Universal service); Wed, 20 Sep 2006 09:01:44 -0700 X-PGP-Universal: processed; by terminus.local on Wed, 20 Sep 2006 09:01:44 -0700 In-Reply-To: <7.0.1.0.2.20060920140342.036d4e48@afrac.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> From: David Conrad Subject: Re: [Ltru] IANA XML registries Date: Wed, 20 Sep 2006 09:01:41 -0700 To: r&d afrac X-Mailer: Apple Mail (2.752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Jefsey, Lots of questions, most of which I suspect are not really related to ltru. I'll answer these questions here, but I suspect there are better places for continued discussion on these topics. On Sep 20, 2006, at 5:18 AM, r&d afrac wrote: > Do you have a completion date in mind? As I've indicated, we hope to have the first set of XML-ized registries available for comment around the beginning of 2007. Further publication will depend on input from the affected communities. > Do you take advantage of this to make them ISO 11179 conformant? > Will it be organised as an ontology? Will you adopt a Dublin Core > approach? If these are appropriate. I am not an XML expert and will look to others to provide advice on the best way of representing IANA registry data externally. > Will you include a secure update annoucement list? I'm unsure of what you mean. We will, in the relatively near future, be PGP signing IANA announcements. > Will you include a consistency check solution for comparing two > versions of a registry? Yes. > Will you include a daily distributed status of these checks to > avoid millions of unnecessary down loads. Hadn't considered it, but if this is desirable, IANA can publish diffs of the registry updates. > Will you include a single IANA procedure for registry management > and review (mailing list, reviewer, appeals, cross registry > consistency, CVS). Having a consistent approach to registry management is a goal. How we manage registries internally is something that is evolving (as you might guess). > Will you support a multilingual approach? Not IANA's call. What is contained within the vast majority of registries is defined by the IETF. > Have you planned a distributed dissemination mechanism? There have been discussions along these lines, but nothing formalized as yet. > Have you planned a procedure/hooks for personal extensions? No. Rgds, -drc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 12:46:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ5DO-0001cn-GQ; Wed, 20 Sep 2006 12:46:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ5DM-0001cZ-W1 for ltru@ietf.org; Wed, 20 Sep 2006 12:46:24 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ5DL-0003w7-Nh for ltru@ietf.org; Wed, 20 Sep 2006 12:46:24 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GQ5DK-0008GP-HB; Wed, 20 Sep 2006 12:46:22 -0400 Date: Wed, 20 Sep 2006 12:46:22 -0400 To: David Conrad Subject: Re: [Ltru] IANA XML registries Message-ID: <20060920164622.GF15905@ccil.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org David Conrad scripsit: > >Will you include a daily distributed status of these checks to > >avoid millions of unnecessary down loads. > > Hadn't considered it, but if this is desirable, IANA can publish > diffs of the registry updates. This is indeed a valid LTRU concern, because at the end of the RFC 4646bis process our registry will grow to about a megabyte. We definitely don't want to see widely distributed software hitting the iana.org server to download it daily or even more often, given that changes will be much more infrequent (based on history). This list has discussed several methods of avoiding such an outcome, from encouraging the use of the HTTP HEAD method or the If-Modified-Since header, to a separate file containing the most recent registry file date, to full provision of diffs. IANA clearly has a stake in the outcome of that conversation. (My opinion FWIW is that a separate short file containing just the file-date record, without full diffs, is the best and simplest proposal.) -- John Cowan cowan@ccil.org http://ccil.org/~cowan [R]eversing the apostolic precept to be all things to all men, I usually [before Darwin] defended the tenability of the received doctrines, when I had to do with the [evolution]ists; and stood up for the possibility of [evolution] among the orthodox -- thereby, no doubt, increasing an already current, but quite undeserved, reputation for needless combativeness. --T. H. Huxley _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 13:53:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6Fc-0005OY-Oc; Wed, 20 Sep 2006 13:52:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6Fb-0005OS-JX for ltru@ietf.org; Wed, 20 Sep 2006 13:52:47 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ6Fa-0000qS-9N for ltru@ietf.org; Wed, 20 Sep 2006 13:52:47 -0400 Received: from terminus.local (dhcp-37-248.icann.org [192.0.37.248]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id k8KHqnFd020570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Sep 2006 10:52:49 -0700 Received: from [127.0.0.1] by terminus.local (PGP Universal service); Wed, 20 Sep 2006 10:52:07 -0700 X-PGP-Universal: processed; by terminus.local on Wed, 20 Sep 2006 10:52:07 -0700 In-Reply-To: <20060920164622.GF15905@ccil.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: David Conrad Subject: Re: [Ltru] IANA XML registries Date: Wed, 20 Sep 2006 10:52:06 -0700 To: John Cowan X-Mailer: Apple Mail (2.752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John, On Sep 20, 2006, at 9:46 AM, John Cowan wrote: > This list has discussed several methods of avoiding such an outcome, > from encouraging the use of the HTTP HEAD method or the If-Modified- > Since > header, to a separate file containing the most recent registry file > date, > to full provision of diffs. IANA clearly has a stake in the > outcome of > that conversation. > > (My opinion FWIW is that a separate short file containing just the > file-date record, without full diffs, is the best and simplest > proposal.) Internally, we use subversion for version control. It would be relatively straight forward for us to provide an opt-in mailing list that broadcasts the contextual diffs of any registry update. We can, of course, also look at other alternatives people might suggest. Rgds, -drc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 14:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6Xm-0002P6-WE; Wed, 20 Sep 2006 14:11:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6Xl-0002Oy-Db for ltru@ietf.org; Wed, 20 Sep 2006 14:11:33 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ6Xj-0004jf-2a for ltru@ietf.org; Wed, 20 Sep 2006 14:11:33 -0400 Received: from terminus.local (dhcp-37-248.icann.org [192.0.37.248]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id k8KIBqqP020633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Sep 2006 11:11:52 -0700 Received: from [127.0.0.1] by terminus.local (PGP Universal service); Wed, 20 Sep 2006 11:11:10 -0700 X-PGP-Universal: processed; by terminus.local on Wed, 20 Sep 2006 11:11:10 -0700 In-Reply-To: <004301c6dc6d$bebab190$6401a8c0@DGBP7M81> References: <008601c6dbf6$8238dc00$6401a8c0@DGBP7M81> <451006C2.60603@yahoo-inc.com> <004301c6dc6d$bebab190$6401a8c0@DGBP7M81> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: <969B72EA-3C02-4132-9B63-DCD1156E5C6C@icann.org> From: David Conrad Subject: Re: [Ltru] Re: zh-hakka Date: Wed, 20 Sep 2006 11:11:08 -0700 To: Doug Ewell X-Mailer: Apple Mail (2.752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Frank Ellermann , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, On Sep 19, 2006, at 9:32 PM, Doug Ewell wrote: > IANA is not perfect. Indeed. We apologize for any errors that might have cropped up during IANA processing of registry modification requests and we'd be very interested in working with interested parties in improving our processes such that those errors aren't repeated (this is one of the reasons why we're doing the internal XMLization -- it enables simpler automation the registry modifications). > In the next few weeks, or months or something, ISO 3166/MA will > decide on new alpha-2 code elements for Serbia and for Montenegro, > now that they have agreed to break up. I don't have any inside > knowledge on what the code elements will be, but two widely > reported possibilities are SP and ME, so let's assume that for now. Actually, I believe they're planning on proposing RS for Serbia... Rgds, -drc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 14:18:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6eP-0006um-Vy; Wed, 20 Sep 2006 14:18:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6eO-0006uh-T2 for ltru@ietf.org; Wed, 20 Sep 2006 14:18:24 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ6eN-0005Sq-MK for ltru@ietf.org; Wed, 20 Sep 2006 14:18:24 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GQ6eN-00037p-Cy; Wed, 20 Sep 2006 14:18:23 -0400 Date: Wed, 20 Sep 2006 14:18:23 -0400 To: David Conrad Subject: Re: [Ltru] IANA XML registries Message-ID: <20060920181823.GK15905@ccil.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org David Conrad scripsit: > Internally, we use subversion for version control. It would be > relatively straight forward for us to provide an opt-in mailing list > that broadcasts the contextual diffs of any registry update. We can, > of course, also look at other alternatives people might suggest. That would be useful for someone like Doug (except that he's the Official Doug of ietf-languages, and already knows what the changes will be), whose langtag-picking program has a version of the registry compiled in. But if I write a picker or validator that does *not* have a compiled-in registry, I would want something more scalable than downloading the whole registry every time the program starts up. If the current File-Date: is provided as a separate IANA resource, I can instead cache the registry locally and then compare the cached File-Date: with the current one, and then download a new instance of the registry only if it has changed. That's equivalent to using the HTTP HEAD method, but easier to do using higher-level facilities that just fetch URIs rather than providing general HTTP capability. Such a scheme is much easier than applying diffs sent out by you, not to mention that I probably won't have access to the user's mail agent to subscribe to the list or collect the diffs from it. -- John Cowan cowan@ccil.org "Mr. Lane, if you ever wish anything that I can do, all you will have to do will be to send me a telegram asking and it will be done." "Mr. Hearst, if you ever get a telegram from me asking you to do anything, you can put the telegram down as a forgery." _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 14:39:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6yH-0008DO-I6; Wed, 20 Sep 2006 14:38:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6yH-0008DG-22 for ltru@ietf.org; Wed, 20 Sep 2006 14:38:57 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ6yF-0000Zt-NV for ltru@ietf.org; Wed, 20 Sep 2006 14:38:57 -0400 Received: from terminus.local (dhcp-37-248.icann.org [192.0.37.248]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id k8KIdLEi020741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Sep 2006 11:39:21 -0700 Received: from [127.0.0.1] by terminus.local (PGP Universal service); Wed, 20 Sep 2006 11:38:39 -0700 X-PGP-Universal: processed; by terminus.local on Wed, 20 Sep 2006 11:38:39 -0700 In-Reply-To: <20060920181823.GK15905@ccil.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> <20060920181823.GK15905@ccil.org> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <04FF8B53-02ED-4087-89FB-48ABAF4BD753@icann.org> From: David Conrad Subject: Re: [Ltru] IANA XML registries Date: Wed, 20 Sep 2006 11:38:37 -0700 To: John Cowan X-Mailer: Apple Mail (2.752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, On Sep 20, 2006, at 11:18 AM, John Cowan wrote: > But if I write a picker or validator that does *not* have a > compiled-in > registry, I would want something more scalable than downloading the > whole > registry every time the program starts up. Makes sense. > If the current File-Date: is > provided as a separate IANA resource, I can instead cache the registry > locally and then compare the cached File-Date: with the current one, > and then download a new instance of the registry only if it has > changed. The implication of this is that the entire registry would need to be fetched, right? Given I'm told the registry under discussion is a bit on the large-ish size, this might be somewhat problematic. Can you give me an idea of the anticipated scale of the number of applications that will be wanting to fetch this registry? I'm curious: is there a way the registry could be broken down in a hierarchical fashion such that only the sub-trees or leaves that change would need to be downloaded? Obviously I'm a newcomer to this list and ignorant of previous discussions so apologies if this has been discussed to death previously... Rgds, -drc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 16:07:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8ME-0004Yq-Bp; Wed, 20 Sep 2006 16:07:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8MC-0004Yg-Nx for ltru@ietf.org; Wed, 20 Sep 2006 16:07:44 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ8MA-00063h-3o for ltru@ietf.org; Wed, 20 Sep 2006 16:07:44 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 25CCF240814; Wed, 20 Sep 2006 22:07:22 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id EB0E01117B; Wed, 20 Sep 2006 22:04:54 +0200 (CEST) Date: Wed, 20 Sep 2006 22:04:54 +0200 From: Stephane Bortzmeyer To: David Conrad Message-ID: <20060920200454.GA27062@sources.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> <20060920181823.GK15905@ccil.org> <04FF8B53-02ED-4087-89FB-48ABAF4BD753@icann.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04FF8B53-02ED-4087-89FB-48ABAF4BD753@icann.org> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org Subject: [Ltru] Re: IANA XML registries X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Wed, Sep 20, 2006 at 11:38:37AM -0700, David Conrad wrote a message of 39 lines which said: > Can you give me an idea of the anticipated scale of the number of > applications that will be wanting to fetch this registry? Do note that RFC 4646 clearly mentions that access to the registry is *not* necessary for successful parsing of language tags. Indeed, the RFC authors take great pain to ensure that tags could be checked offline, without a copy of the registry. [Side note: what JFC Morfin wrote about my parser is completely false.] > I'm curious: is there a way the registry could be broken down in a > hierarchical fashion such that only the sub-trees or leaves that > change would need to be downloaded? The issue of performance is a complex one because there are many possible solutions (Web caches like Squid being an obvious one). Distributions by redistributors, and local storage, like it is currently done with XML schemas, to avoid killing the W3C Web servers, is another one. I do not think there is *one* approach to this problem. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 16:09:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8Nj-0007hP-Mz; Wed, 20 Sep 2006 16:09:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8Ni-0007fx-U6 for ltru@ietf.org; Wed, 20 Sep 2006 16:09:18 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ8Nd-0006FR-Gl for ltru@ietf.org; Wed, 20 Sep 2006 16:09:18 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004734079.msg for ; Wed, 20 Sep 2006 21:10:43 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Wed, 20 Sep 2006 21:09:07 +0100 From: "Debbie Garside" To: , "'John Cowan'" Subject: RE: [Ltru] IANA XML registries Date: Wed, 20 Sep 2006 21:08:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: Acbc5G08LAber+yYRbibDpaKiCtWzQAChyiw In-Reply-To: <04FF8B53-02ED-4087-89FB-48ABAF4BD753@icann.org> Message-ID: X-Spam-Processed: mx1.nexbyte.net, Wed, 20 Sep 2006 21:10:43 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Wed, 20 Sep 2006 21:10:44 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: 'Doug Ewell' , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org David Conrad wrote: > I'm curious: is there a way the registry could be broken down > in a hierarchical fashion such that only the sub-trees or > leaves that change would need to be downloaded? Obviously > I'm a newcomer to this list and ignorant of previous > discussions so apologies if this has been discussed to death > previously... I think this could be a very good idea and should be investigated. However, one way to do this is to update the registry but to create "Newsletter" type pages with any additions (bit like they do for ISO 3166-1). The WatchThisPage function could then be utilised. Those code elements included in the Newsletters could then be appended to the local registry file, thus negating the need to download the whole registry again. This would work in database terms but only for NEW registry items, not changes to existing code elements. I cannot say how this would work with bespoke applications. I am sure Doug can give us the statistics for New Items and Change Items in the past 12 months! Doug? I think John's idea of publishing the "Registry Last Updated" date is a good one too. Both suggestions would encourage less downloads of the whole Registry file. Best regards Debbie Garside > -----Original Message----- > From: David Conrad [mailto:david.conrad@icann.org] > Sent: 20 September 2006 19:39 > To: John Cowan > Cc: ltru@ietf.org > Subject: Re: [Ltru] IANA XML registries > > Hi, > > On Sep 20, 2006, at 11:18 AM, John Cowan wrote: > > But if I write a picker or validator that does *not* have a > > compiled-in registry, I would want something more scalable than > > downloading the whole registry every time the program starts up. > > Makes sense. > > > If the current File-Date: is > > provided as a separate IANA resource, I can instead cache > the registry > > locally and then compare the cached File-Date: with the > current one, > > and then download a new instance of the registry only if it has > > changed. > > The implication of this is that the entire registry would > need to be fetched, right? Given I'm told the registry under > discussion is a bit on the large-ish size, this might be > somewhat problematic. Can you give me an idea of the > anticipated scale of the number of applications that will be > wanting to fetch this registry? > > I'm curious: is there a way the registry could be broken down > in a hierarchical fashion such that only the sub-trees or > leaves that change would need to be downloaded? Obviously > I'm a newcomer to this list and ignorant of previous > discussions so apologies if this has been discussed to death > previously... > > Rgds, > -drc > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 16:09:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8Np-0007tU-Uq; Wed, 20 Sep 2006 16:09:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8Np-0007tP-19 for ltru@ietf.org; Wed, 20 Sep 2006 16:09:25 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ8Nn-0006Ft-QN for ltru@ietf.org; Wed, 20 Sep 2006 16:09:25 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GQ8Nn-0006yV-9y; Wed, 20 Sep 2006 16:09:23 -0400 Date: Wed, 20 Sep 2006 16:09:23 -0400 To: David Conrad Subject: Re: [Ltru] IANA XML registries Message-ID: <20060920200923.GP15905@ccil.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> <20060920181823.GK15905@ccil.org> <04FF8B53-02ED-4087-89FB-48ABAF4BD753@icann.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04FF8B53-02ED-4087-89FB-48ABAF4BD753@icann.org> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org David Conrad scripsit: > The implication of this is that the entire registry would need to be > fetched, right? Given I'm told the registry under discussion is a > bit on the large-ish size, this might be somewhat problematic. The idea is to fetch the registry only when it changes, and looking over the history of the registry and its predecessor, it has only changed three times a year on average. > Can you give me an idea of the anticipated scale of the number of > applications that will be wanting to fetch this registry? It's not the number of applications, it's the number of *instances* of those applications that is at stake, and that's unforeseeable right now. > I'm curious: is there a way the registry could be broken down in a > hierarchical fashion such that only the sub-trees or leaves that > change would need to be downloaded? Obviously I'm a newcomer to this > list and ignorant of previous discussions so apologies if this has > been discussed to death previously... Not really. There are six kinds of entries in the registry (language, region, script, variant, grandfathered, redundant), but a change is equally likely in any of them. In any case, most people will only need a few of the registry's entries, but it will be unpredictable which few. -- Principles. You can't say A is John Cowan made of B or vice versa. All mass http://www.ccil.org/~cowan is interaction. --Richard Feynman _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 16:22:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8aS-0006eo-Mm; Wed, 20 Sep 2006 16:22:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8aS-0006e3-6R for ltru@ietf.org; Wed, 20 Sep 2006 16:22:28 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ8a8-0000O4-Uz for ltru@ietf.org; Wed, 20 Sep 2006 16:22:28 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id AD44A240814; Wed, 20 Sep 2006 22:22:05 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 07F5B11B26; Wed, 20 Sep 2006 22:19:45 +0200 (CEST) Date: Wed, 20 Sep 2006 22:19:45 +0200 From: Stephane Bortzmeyer To: David Conrad , LTRU Working Group Message-ID: <20060920201945.GB27062@sources.org> References: <008601c6dbf6$8238dc00$6401a8c0@DGBP7M81> <451006C2.60603@yahoo-inc.com> <004301c6dc6d$bebab190$6401a8c0@DGBP7M81> <969B72EA-3C02-4132-9B63-DCD1156E5C6C@icann.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <969B72EA-3C02-4132-9B63-DCD1156E5C6C@icann.org> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] Re: zh-hakka X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Wed, Sep 20, 2006 at 11:11:08AM -0700, David Conrad wrote a message of 28 lines which said: > We apologize for any errors that might have cropped up during IANA > processing of registry modification requests and we'd be very > interested in working with interested parties in improving our > processes such that those errors aren't repeated (this is one of the > reasons why we're doing the internal XMLization -- it enables > simpler automation the registry modifications). Automatically testing the registry to catch syntax errors or inconsistencies is so obvious that I'm surprised it is not done yet :-} It's the equivalent of integrity rules in DBMS. To do it, there are several possibilities: using XML + a schema language like RelaxNG + a rule language like Schematron is certainly a possible way. Using a custom program is possible, too. Does anyone have one for LTRU (I might write it myself otherwise)? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 16:27:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8eu-00066k-O0; Wed, 20 Sep 2006 16:27:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8eu-00066f-1w for ltru@ietf.org; Wed, 20 Sep 2006 16:27:04 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ8es-0001UT-Qs for ltru@ietf.org; Wed, 20 Sep 2006 16:27:04 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GQ8es-0007XY-Fl; Wed, 20 Sep 2006 16:27:02 -0400 Date: Wed, 20 Sep 2006 16:27:02 -0400 To: Stephane Bortzmeyer Message-ID: <20060920202702.GQ15905@ccil.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> <20060920181823.GK15905@ccil.org> <04FF8B53-02ED-4087-89FB-48ABAF4BD753@icann.org> <20060920200454.GA27062@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060920200454.GA27062@sources.org> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ltru@ietf.org Subject: [Ltru] Re: IANA XML registries X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer scripsit: > Do note that RFC 4646 clearly mentions that access to the registry is > *not* necessary for successful parsing of language tags. Indeed, the > RFC authors take great pain to ensure that tags could be checked > offline, without a copy of the registry. Parsing is indeed possible without the registry: with a very small amount of embedded permanent knowledge, an RFC 4646 language tag can be decomposed into language, script, region, variant, extension, and private-use subtags, or else identified as a grandfathered tag that cannot be decomposed. However, selecting language tags or determining their validity (as opposed to well-formedness) requires a copy of the registry. > The issue of performance is a complex one because there are many > possible solutions (Web caches like Squid being an obvious > one). Distributions by redistributors, and local storage, like it is > currently done with XML schemas, to avoid killing the W3C Web servers, > is another one. We've already heard, however, that a large portion of the load on those same W3C servers is from validating parsers that are unnecessarily fetching DTDs for common XML document types like XHTML. > I do not think there is *one* approach to this problem. +1 -- John Cowan cowan@ccil.org http://ccil.org/~cowan Female celebrity stalker, on a hot morning in Cairo: "Imagine, Colonel Lawrence, ninety-two already!" El Auruns's reply: "Many happy returns of the day!" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 16:29:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8gn-0007Nk-Tv; Wed, 20 Sep 2006 16:29:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8gn-0007Nf-G4 for ltru@ietf.org; Wed, 20 Sep 2006 16:29:01 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ8gl-0001v2-J8 for ltru@ietf.org; Wed, 20 Sep 2006 16:29:00 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8KKSocv005062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 Sep 2006 13:28:51 -0700 Received: from [10.0.1.2] (vpn-10-50-0-193.qualcomm.com [10.50.0.193]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8KKSlu1014706; Wed, 20 Sep 2006 13:28:48 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060920200454.GA27062@sources.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> <20060920181823.GK15905@ccil.org> <04FF8B53-02ED-4087-89FB-48ABAF4BD753@icann.org> <20060920200454.GA27062@sources.org> Date: Wed, 20 Sep 2006 13:28:45 -0700 To: Stephane Bortzmeyer , David Conrad From: Ted Hardie Subject: [Ltru] Re: IANA XML registries Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 10:04 PM +0200 9/20/06, Stephane Bortzmeyer wrote: >On Wed, Sep 20, 2006 at 11:38:37AM -0700, > David Conrad wrote > a message of 39 lines which said: > >> Can you give me an idea of the anticipated scale of the number of >> applications that will be wanting to fetch this registry? > >Do note that RFC 4646 clearly mentions that access to the registry is >*not* necessary for successful parsing of language tags. Indeed, the >RFC authors take great pain to ensure that tags could be checked >offline, without a copy of the registry. > I've just been having a side discussion on this topic, so let me be sure I'm clear about this. There are two types of check: for well-formedness and for validity. For well-formedness, you do need access to the list of grandfathered tags, since they are part of the check in 2.2.9 of 4646: > An implementation that claims to check for well-formed language tags > MUST: > > o Check that the tag and all of its subtags, including extension and > private use subtags, conform to the ABNF or that the tag is on the > list of grandfathered tags. Validity is associated with registry date for which the implementation performs validity checks, and access to a copy of the registry for that date is needed: An implementation that claims to be validating MUST: * Check that the tag is well-formed. o Specify the particular registry date for which the implementation performs validation of subtags. o Check that either the tag is a grandfathered tag, or that all language, script, region, and variant subtags consist of valid codes for use in language tags according to the IANA registry as of the particular date specified by the implementation. o Specify which, if any, extension RFCs as defined in Section 3.7 are supported, including version, revision, and date. o For any such extensions supported, check that all subtags used in that extension are valid. o For variant and extended language subtags, if the registry contains one or more 'Prefix' fields for that subtag, check that the tag matches at least one prefix. The tag matches if all the subtags in the 'Prefix' also appear in the tag. For example, the prefix "es-CO" matches the tag "es-Latn-CO-x-private" because both the 'es' language subtag and 'CO' region subtag appear in the tag. The documents statement on accessibility of the registry is: >Although the specification of valid subtags for an extension (see > Section 3.7) MUST be available over the Internet, implementations > SHOULD NOT mechanically depend on it being always accessible, to > prevent denial-of-service attacks. All present and correct? Ted _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 16:33:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8kl-0002px-7E; Wed, 20 Sep 2006 16:33:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8kk-0002ks-1u for ltru@ietf.org; Wed, 20 Sep 2006 16:33:06 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ8ki-0002g5-RE for ltru@ietf.org; Wed, 20 Sep 2006 16:33:06 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GQ8ki-0007kU-HS; Wed, 20 Sep 2006 16:33:04 -0400 Date: Wed, 20 Sep 2006 16:33:04 -0400 To: Ted Hardie Subject: Re: [Ltru] Re: IANA XML registries Message-ID: <20060920203304.GR15905@ccil.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> <20060920181823.GK15905@ccil.org> <04FF8B53-02ED-4087-89FB-48ABAF4BD753@icann.org> <20060920200454.GA27062@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Ted Hardie scripsit: > All present and correct? Yes. In RFC 4646bis, we expect all these things to be maintained; however, the registry will become much larger (~ 1MB), so any performance-related issues will bite all the harder. -- Verbogeny is one of the pleasurettes John Cowan of a creatific thinkerizer. http://www.ccil.org/~cowan -- Peter da Silva _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 17:50:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ9xE-0007tF-64; Wed, 20 Sep 2006 17:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ9xC-0007tA-Ug for ltru@ietf.org; Wed, 20 Sep 2006 17:50:02 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ9xB-0004oO-JY for ltru@ietf.org; Wed, 20 Sep 2006 17:50:02 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8KLnhhE068202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Sep 2006 14:49:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=RlJV1odPBTVJSn2Fq21DEdJdUzXYS711jzr6LStz2Bhc5Nf3/Q1m6dsKMAFaP+bx Message-ID: <4511B776.1090706@yahoo-inc.com> Date: Wed, 20 Sep 2006 14:49:42 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Re: IANA XML registries References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> <20060920181823.GK15905@ccil.org> <04FF8B53-02ED-4087-89FB-48ABAF4BD753@icann.org> <20060920200454.GA27062@sources.org> <20060920202702.GQ15905@ccil.org> In-Reply-To: <20060920202702.GQ15905@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > > However, selecting language tags or determining their validity > (as opposed to well-formedness) requires a copy of the registry. > One small nit: selecting language tags does not necessarily require a copy of the registry. Most implementations I'm aware of just have a list of common (valid) tags for the user to choose from or perform rudimentary well-formedness checks on user input. Validating these requires a registry copy, of course. > >> I do not think there is *one* approach to this problem. > > +1 > +1 Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 18:11:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQAHq-0007Iv-Hf; Wed, 20 Sep 2006 18:11:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQAHp-0007In-2B for ltru@ietf.org; Wed, 20 Sep 2006 18:11:21 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQAHn-0008AE-OO for ltru@ietf.org; Wed, 20 Sep 2006 18:11:21 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id E31BE1E1512; Wed, 20 Sep 2006 15:11:16 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Sep 2006 15:11:16 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EF02@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Addison Phillips' , John Cowan Subject: RE: [Ltru] Re: IANA XML registries Date: Wed, 20 Sep 2006 15:11:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, Diffs (actual line-by-line comparisons) aren't really useful. But an update file that contains _whole_records_ for subtags either modified or new would be sufficient, when combined with John's good idea for a separate file-date-version HTTP resource. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: Wednesday, September 20, 2006 5:50 PM > To: John Cowan > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: IANA XML registries > > > > > John Cowan wrote: > > > > However, selecting language tags or determining their validity > > (as opposed to well-formedness) requires a copy of the registry. > > > > One small nit: selecting language tags does not necessarily require a > copy of the registry. Most implementations I'm aware of just > have a list > of common (valid) tags for the user to choose from or perform > rudimentary well-formedness checks on user input. Validating these > requires a registry copy, of course. > > > > >> I do not think there is *one* approach to this problem. > > > > +1 > > > > +1 > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.5/451 - Release Date: 9/19/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 18:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQAuf-0004HW-Fn; Wed, 20 Sep 2006 18:51:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQAud-0004GA-Pa for ltru@lists.ietf.org; Wed, 20 Sep 2006 18:51:27 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQAua-00018L-D4 for ltru@lists.ietf.org; Wed, 20 Sep 2006 18:51:27 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GQAuH-0006kc-Dn for ltru@lists.ietf.org; Thu, 21 Sep 2006 00:51:05 +0200 Received: from pd9fbad47.dip0.t-ipconnect.de ([217.251.173.71]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Sep 2006 00:51:05 +0200 Received: from nobody by pd9fbad47.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Sep 2006 00:51:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 21 Sep 2006 00:49:24 +0200 Organization: Lines: 17 Message-ID: <4511C574.3A8D@xyzzy.claranet.de> References: <008601c6dbf6$8238dc00$6401a8c0@DGBP7M81> <451006C2.60603@yahoo-inc.com> <004301c6dc6d$bebab190$6401a8c0@DGBP7M81> <969B72EA-3C02-4132-9B63-DCD1156E5C6C@icann.org> <20060920201945.GB27062@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad47.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Re: zh-hakka X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > Using a custom program is possible, too. Does anyone > have one for LTRU (I might write it myself otherwise)? Doug has one (I think), and I've a REXX script for the 4646 format (= no extlang), mainly to create a table of Suppress-Scripts, but also doing case-insensitive XREFs, and listing the known "deprecated before added" cases. I plan to improve the DTD-based ID + IDREF(S) check to use a format that might also work for Debbie's purpose, apparently that needs your "elements for everything" approach (, , ) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 18:56:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQAzq-0001ZM-Pb; Wed, 20 Sep 2006 18:56:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQAzp-0001ZD-I9 for ltru@lists.ietf.org; Wed, 20 Sep 2006 18:56:49 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQAzo-0002bl-9B for ltru@lists.ietf.org; Wed, 20 Sep 2006 18:56:49 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GQAzb-0007fB-Oc for ltru@lists.ietf.org; Thu, 21 Sep 2006 00:56:35 +0200 Received: from pd9fbad47.dip0.t-ipconnect.de ([217.251.173.71]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Sep 2006 00:56:35 +0200 Received: from nobody by pd9fbad47.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Sep 2006 00:56:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 21 Sep 2006 00:55:56 +0200 Organization: Lines: 10 Message-ID: <4511C6FC.190D@xyzzy.claranet.de> References: <008101c6dcb5$82dfbc90$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad47.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] Re: split section 3.1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > "it's right there in 'War and Peace,' go look it up." One of the reasons why I think that attempts to get rid of the hilarious "page numbers" in RFCs are premature, rfcmarkup creates #page-1 etc. fragments as last resort. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 20 19:25:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQBR7-0000g4-Vm; Wed, 20 Sep 2006 19:25:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQBR6-0000fv-PR for ltru@lists.ietf.org; Wed, 20 Sep 2006 19:25:00 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQBR5-0000aT-Bg for ltru@lists.ietf.org; Wed, 20 Sep 2006 19:25:00 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GQBQy-0004kP-KG for ltru@lists.ietf.org; Thu, 21 Sep 2006 01:24:52 +0200 Received: from pd9fbad47.dip0.t-ipconnect.de ([217.251.173.71]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Sep 2006 01:24:52 +0200 Received: from nobody by pd9fbad47.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Sep 2006 01:24:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 21 Sep 2006 01:20:43 +0200 Organization: Lines: 43 Message-ID: <4511CCCB.66C5@xyzzy.claranet.de> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> <20060920181823.GK15905@ccil.org> <04FF8B53-02ED-4087-89FB-48ABAF4BD753@icann.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad47.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Ltru] Re: IANA XML registries X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org David Conrad wrote: > I'm curious: is there a way the registry could be broken down > in a hierarchical fashion such that only the sub-trees or > leaves that change would need to be downloaded? It has "records" (roughly reflecting a registration template) of different "types" (language, script, region, etc.), and while RFC 4646 allows you to organize it in any way you like, it does reqire an organization "by type". So you can sort say languages in any way that makes sense for you, e.g. chronologically (by "added"), or alphabetically (by "subtag"), or in the input order (by subtag length and then alphabetically within the same length) as provided by Doug. Breaking it up "by type" is logical, but doesn't help much, most records are languages. We could remove the requirement to organize it by type in 4646bis. Then you'd be free to organize it alphabetically [0..9A..Za..z] (case-sensitive). Unfortunately that (also) won't help much for "what's new" queries, it would only allow faster access on given subtags for users without clue about the various types. The idea (so far) is that you organize it as required, and that third parties offer the various interesting "views" on the complete data. Frank Obviously I'm a newcomer to this > list and ignorant of previous discussions so apologies if this has > been discussed to death previously... > > Rgds, > -drc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 01:20:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQGyz-0005Uh-0a; Thu, 21 Sep 2006 01:20:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQGyx-0005UY-MK for ltru@ietf.org; Thu, 21 Sep 2006 01:20:19 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQGyt-0000OV-D3 for ltru@ietf.org; Thu, 21 Sep 2006 01:20:19 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060921052014.VUHJ17675.mta9.adelphia.net@DGBP7M81>; Thu, 21 Sep 2006 01:20:14 -0400 Message-ID: <006f01c6dd3d$9ed60ed0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <008601c6dbf6$8238dc00$6401a8c0@DGBP7M81> <451006C2.60603@yahoo-inc.com> <004301c6dc6d$bebab190$6401a8c0@DGBP7M81> <969B72EA-3C02-4132-9B63-DCD1156E5C6C@icann.org> Subject: Re: [Ltru] Re: zh-hakka Date: Wed, 20 Sep 2006 22:20:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Frank Ellermann X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org David Conrad wrote: >> IANA is not perfect. > > Indeed. We apologize for any errors that might have cropped up during > IANA processing of registry modification requests and we'd be very > interested in working with interested parties in improving our > processes such that those errors aren't repeated (this is one of the > reasons why we're doing the internal XMLization -- it enables simpler > automation the registry modifications). No problem. I'm sure you won't mind some extra pairs of eyes to help maintain a high standard of quality. (BTW, the new 2006-09-20 version of the Registry looks great.) >> In the next few weeks, or months or something, ISO 3166/MA will >> decide on new alpha-2 code elements for Serbia and for Montenegro, >> now that they have agreed to break up. I don't have any inside >> knowledge on what the code elements will be, but two widely reported >> possibilities are SP and ME, so let's assume that for now. > > Actually, I believe they're planning on proposing RS for Serbia... I know the Serbian government proposed RS (for "Republic of Serbia"), and I've heard alternatively that ISO (a) supports it or (b) opposes it because of their policy against using words like "Republic" to make the code element. I guess we won't know for sure until the formal announcement. In any case, I was just using it for illustration. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 01:30:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQH8f-0002Dn-7E; Thu, 21 Sep 2006 01:30:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQH8e-0002Di-0G for ltru@ietf.org; Thu, 21 Sep 2006 01:30:20 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQH8Z-0001qe-OM for ltru@ietf.org; Thu, 21 Sep 2006 01:30:19 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060921053014.LNVI25133.mta11.adelphia.net@DGBP7M81>; Thu, 21 Sep 2006 01:30:14 -0400 Message-ID: <007501c6dd3f$04adb950$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] IANA XML registries Date: Wed, 20 Sep 2006 22:30:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: > I am sure Doug can give us the statistics for New Items and Change > Items in the past 12 months! Doug? Since the initial rollout of the Language Subtag Registry dated 2005-10-16, there have been 8 updates (including one just today, on 2006-09-20), for an average of one update every 8 weeks. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 01:53:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQHUf-0005x5-5m; Thu, 21 Sep 2006 01:53:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQHUe-0005wx-2j for ltru@ietf.org; Thu, 21 Sep 2006 01:53:04 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQHUa-0005OT-Ol for ltru@ietf.org; Thu, 21 Sep 2006 01:53:04 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060921055255.BUDB12100.mta13.adelphia.net@DGBP7M81> for ; Thu, 21 Sep 2006 01:52:55 -0400 Message-ID: <00ad01c6dd42$2fb15a50$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 20 Sep 2006 22:52:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ltru] Proofreading the Registry (was: Re: zh-hakka) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > Automatically testing the registry to catch syntax errors or > inconsistencies is so obvious that I'm surprised it is not done yet > :-} It's the equivalent of integrity rules in DBMS. I do have a program that does this, but it is a private hack that would need serious cleaning-up before I could distribute it and still sleep nights. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 02:01:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQHcM-00022p-LV; Thu, 21 Sep 2006 02:01:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQHcL-00022h-Us for ltru@ietf.org; Thu, 21 Sep 2006 02:01:01 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQHcH-0006WY-MM for ltru@ietf.org; Thu, 21 Sep 2006 02:01:01 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060921060057.QLKX14728.mta10.adelphia.net@DGBP7M81> for ; Thu, 21 Sep 2006 02:00:57 -0400 Message-ID: <00b101c6dd43$4e9ae840$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 20 Sep 2006 23:00:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ltru] Re: IANA XML registries X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > Breaking it up "by type" is logical, but doesn't help much, most > records are languages. We could remove the requirement to organize it > by type in 4646bis. Then you'd be free to organize it alphabetically > [0..9A..Za..z] (case-sensitive). I can't speak for anyone else, but it helps me quite a bit that the records are grouped by type. I'd be opposed to changing this. In fact, I'd want to go the other way, tighting up Section 5.1 to require subtags to be in alphabetical order, and further splitting the "language" subtags into 2-letter and 3-letter subgroups and putting "anp" and "frr" back in the 3-letter subgroup. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 02:12:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQHnd-0000hG-61; Thu, 21 Sep 2006 02:12:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQHnb-0000aw-Sd for ltru@lists.ietf.org; Thu, 21 Sep 2006 02:12:39 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQHnU-00015u-E0 for ltru@lists.ietf.org; Thu, 21 Sep 2006 02:12:39 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GQHnM-0002ge-06 for ltru@lists.ietf.org; Thu, 21 Sep 2006 08:12:24 +0200 Received: from pd9fba905.dip0.t-ipconnect.de ([217.251.169.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Sep 2006 08:12:23 +0200 Received: from nobody by pd9fba905.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Sep 2006 08:12:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 21 Sep 2006 08:09:24 +0200 Organization: Lines: 12 Message-ID: <45122C94.3D5@xyzzy.claranet.de> References: <008601c6dbf6$8238dc00$6401a8c0@DGBP7M81> <451006C2.60603@yahoo-inc.com> <004301c6dc6d$bebab190$6401a8c0@DGBP7M81> <969B72EA-3C02-4132-9B63-DCD1156E5C6C@icann.org> <006f01c6dd3d$9ed60ed0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba905.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.5 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: zh-hakka X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > the new 2006-09-20 version of the Registry looks great. validator.w3.org agrees with that: http://validator.w3.org/check?uri=http%3A%2F%2Fxyzzy.webhop.info%2Fhome%2Fltru%2Flstreg9.xml Ignore the US-ASCII blurb, my other provider would send the missing charset=us-ascii parameter for Content-Type: text/xml Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 02:26:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQI1G-0007dZ-8z; Thu, 21 Sep 2006 02:26:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQI1D-0007dU-8O for ltru@lists.ietf.org; Thu, 21 Sep 2006 02:26:43 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQI18-0006e4-U3 for ltru@lists.ietf.org; Thu, 21 Sep 2006 02:26:43 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GQI0v-0005JT-8d for ltru@lists.ietf.org; Thu, 21 Sep 2006 08:26:25 +0200 Received: from pd9fba905.dip0.t-ipconnect.de ([217.251.169.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Sep 2006 08:26:25 +0200 Received: from nobody by pd9fba905.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Sep 2006 08:26:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 21 Sep 2006 08:25:41 +0200 Organization: Lines: 19 Message-ID: <45123065.2EE0@xyzzy.claranet.de> References: <00b101c6dd43$4e9ae840$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba905.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: IANA XML registries X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > it helps me quite a bit that the records are grouped by type. For users who have no clue what is what a purely alphabetical view could be interesting. I don't care how it's sorted (of course it must be type because 4646 says so). > tighting up Section 5.1 to require subtags to be in > alphabetical order, and further splitting the "language" > subtags into 2-letter and 3-letter subgroups and putting > "anp" and "frr" back in the 3-letter subgroup. That's what I dubbed "input order" in another message. We would need four subgroups: two / three / four letters, and five to eight letters. The last two empty at the moment. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 05:55:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHI-0006qW-78; Thu, 21 Sep 2006 05:55:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHG-0006qI-4n for ltru@ietf.org; Thu, 21 Sep 2006 05:55:30 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQLH9-0000A5-AT for ltru@ietf.org; Thu, 21 Sep 2006 05:55:30 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8L9tBmB028098 for ; Thu, 21 Sep 2006 18:55:11 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 2a6d_45780006_4957_11db_811b_0014221fa3c9; Thu, 21 Sep 2006 18:55:10 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:54217) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 21 Sep 2006 18:55:12 +0900 Message-Id: <6.0.0.20.2.20060921180422.09d3b6c0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 21 Sep 2006 18:05:27 +0900 To: John Cowan , David Conrad From: Martin Duerst Subject: Re: [Ltru] IANA XML registries In-Reply-To: <20060920164622.GF15905@ccil.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 01:46 06/09/21, John Cowan wrote: >(My opinion FWIW is that a separate short file containing just the >file-date record, without full diffs, is the best and simplest proposal.) My personal opinion is that the HTTP mechanisms are best, because already widely implemented. In addition to the two mechanisms mentioned (HEAD, If-Modified-Since), there are also Etags (hash values that can be used to check for changes) and I seem to remember that there is also some diff mechanism (I guess from WebDAV, Lisa?). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 05:55:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHI-0006qa-9T; Thu, 21 Sep 2006 05:55:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHG-0006qQ-Iy for ltru@lists.ietf.org; Thu, 21 Sep 2006 05:55:30 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQLHA-0000B4-TR for ltru@lists.ietf.org; Thu, 21 Sep 2006 05:55:30 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8L9tGs4023427 for ; Thu, 21 Sep 2006 18:55:18 +0900 (JST) Received: from (133.2.206.133) by scmsFrom ltru-bounces@ietf.org Thu Sep 21 05:55:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHI-0006qW-78; Thu, 21 Sep 2006 05:55:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHG-0006qI-4n for ltru@ietf.org; Thu, 21 Sep 2006 05:55:30 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQLH9-0000A5-AT for ltru@ietf.org; Thu, 21 Sep 2006 05:55:30 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8L9tBmB028098 for ; Thu, 21 Sep 2006 18:55:11 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 2a6d_45780006_4957_11db_811b_0014221fa3c9; Thu, 21 Sep 2006 18:55:10 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:54217) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 21 Sep 2006 18:55:12 +0900 Message-Id: <6.0.0.20.2.20060921180422.09d3b6c0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 21 Sep 2006 18:05:27 +0900 To: John Cowan , David Conrad From: Martin Duerst Subject: Re: [Ltru] IANA XML registries In-Reply-To: <20060920164622.GF15905@ccil.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 01:46 06/09/21, John Cowan wrote: >(My opinion FWIW is that a separate short file containing just the >file-date record, without full diffs, is the best and simplest proposal.) My personal opinion is that the HTTP mechanisms are best, because already widely implemented. In addition to the two mechanisms mentioned (HEAD, If-Modified-Since), there are also Etags (hash values that can be used to check for changes) and I seem to remember that there is also some diff mechanism (I guess from WebDAV, Lisa?). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 05:55:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHI-0006qa-9T; Thu, 21 Sep 2006 05:55:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHG-0006qQ-Iy for ltru@lists.ietf.org; Thu, 21 Sep 2006 05:55:30 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQLHA-0000B4-TR for ltru@lists.ietf.org; Thu, 21 Sep 2006 05:55:30 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8L9tGs4023427 for ; Thu, 21 Sep 2006 18:55:18 +0900 (JST) Received: from (133.2.206.133) by scmsFrom ltru-bounces@ietf.org Thu Sep 21 05:55:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHI-0006qW-78; Thu, 21 Sep 2006 05:55:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHG-0006qI-4n for ltru@ietf.org; Thu, 21 Sep 2006 05:55:30 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQLH9-0000A5-AT for ltru@ietf.org; Thu, 21 Sep 2006 05:55:30 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8L9tBmB028098 for ; Thu, 21 Sep 2006 18:55:11 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 2a6d_45780006_4957_11db_811b_0014221fa3c9; Thu, 21 Sep 2006 18:55:10 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:54217) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 21 Sep 2006 18:55:12 +0900 Message-Id: <6.0.0.20.2.20060921180422.09d3b6c0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 21 Sep 2006 18:05:27 +0900 To: John Cowan , David Conrad From: Martin Duerst Subject: Re: [Ltru] IANA XML registries In-Reply-To: <20060920164622.GF15905@ccil.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 01:46 06/09/21, John Cowan wrote: >(My opinion FWIW is that a separate short file containing just the >file-date record, without full diffs, is the best and simplest proposal.) My personal opinion is that the HTTP mechanisms are best, because already widely implemented. In addition to the two mechanisms mentioned (HEAD, If-Modified-Since), there are also Etags (hash values that can be used to check for changes) and I seem to remember that there is also some diff mechanism (I guess from WebDAV, Lisa?). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 05:55:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHI-0006qa-9T; Thu, 21 Sep 2006 05:55:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHG-0006qQ-Iy for ltru@lists.ietf.org; Thu, 21 Sep 2006 05:55:30 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQLHA-0000B4-TR for ltru@lists.ietf.org; Thu, 21 Sep 2006 05:55:30 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8L9tGs4023427 for ; Thu, 21 Sep 2006 18:55:18 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 4f1d_48943174_4957_11db_8c89_0014221f2a2d; Thu, 21 Sep 2006 18:55:16 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:54217) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 21 Sep 2006 18:55:18 +0900 Message-Id: <6.0.0.20.2.20060921183415.0368dd00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 21 Sep 2006 18:54:35 +0900 To: David Conrad , Frank Ellermann From: Martin Duerst Subject: Re: [Ltru] Re: IANA XML registries In-Reply-To: References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello David, At 00:18 06/09/21, David Conrad wrote: >To clarify, the XML-ization of IANA registries is an _internal_ >effort, primarily aimed at allowing us to simplify/automate registry >creation and modification. We will take what efforts we can to >insure there is no significant change to the "legacy" registries. We >will _also_ publish the initial set of XML-ized registries (at >different URLs of course) and request comments. Assuming the initial >forays into XML-ization are deemed acceptable, we'll publish more. >If not (hey, it could happen), we'll not publish more (but we'll >still use the XML registries internally). Many thanks for this clarification, and also for helping with the discussions concerning the size of our new registry and possible consequences of this size. The main reason that you got contacted was that to some extent, we were considering to move from what could be called a 'home-brewn' format to something XML-based. One argument for it was that there was a rumor that IANA would be moving to XML, which you now have confirmed. Given that above, you describe the purpose of XML as mainly internal, I'm wondering whether, in your/IANAs view, an XML format defined by a WG would be: a) desirable (e.g. less work for IANA; helpful external input,...) b) irrelevant (the WG can do what they want, we'll do what we need,...) c) harmful (we'll have to re-do it anyway; it would confuse people,...) Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 05:55:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHL-0006rI-E7; Thu, 21 Sep 2006 05:55:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHI-0006qh-R3 for ltru@ietf.org; Thu, 21 Sep 2006 05:55:32 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQLHC-0000AX-UN for ltru@ietf.org; Thu, 21 Sep 2006 05:55:32 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secree2.scbb.aoyama.ac.jp via smtp id 4f1d_48943174_4957_11db_8c89_0014221f2a2d; Thu, 21 Sep 2006 18:55:16 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:54217) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 21 Sep 2006 18:55:18 +0900 Message-Id: <6.0.0.20.2.20060921183415.0368dd00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 21 Sep 2006 18:54:35 +0900 To: David Conrad , Frank Ellermann From: Martin Duerst Subject: Re: [Ltru] Re: IANA XML registries In-Reply-To: References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello David, At 00:18 06/09/21, David Conrad wrote: >To clarify, the XML-ization of IANA registries is an _internal_ >effort, primarily aimed at allowing us to simplify/automate registry >creation and modification. We will take what efforts we can to >insure there is no significant change to the "legacy" registries. We >will _also_ publish the initial set of XML-ized registries (at >different URLs of course) and request comments. Assuming the initial >forays into XML-ization are deemed acceptable, we'll publish more. >If not (hey, it could happen), we'll not publish more (but we'll >still use the XML registries internally). Many thanks for this clarification, and also for helping with the discussions concerning the size of our new registry and possible consequences of this size. The main reason that you got contacted was that to some extent, we were considering to move from what could be called a 'home-brewn' format to something XML-based. One argument for it was that there was a rumor that IANA would be moving to XML, which you now have confirmed. Given that above, you describe the purpose of XML as mainly internal, I'm wondering whether, in your/IANAs view, an XML format defined by a WG would be: a) desirable (e.g. less work for IANA; helpful external input,...) b) irrelevant (the WG can do what they want, we'll do what we need,...) c) harmful (we'll have to re-do it anyway; it would confuse people,...) Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 05:55:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHL-0006rI-E7; Thu, 21 Sep 2006 05:55:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHI-0006qh-R3 for ltru@ietf.org; Thu, 21 Sep 2006 05:55:32 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQLHC-0000AX-UN for ltru@ietf.org; Thu, 21 Sep 2006 05:55:32 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secree2.scbb.aoyama.ac.jp via smtp id 4f1d_48943174_4957_11db_8c89_0014221f2a2d; Thu, 21 Sep 2006 18:55:16 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:54217) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 21 Sep 2006 18:55:18 +0900 Message-Id: <6.0.0.20.2.20060921183415.0368dd00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 21 Sep 2006 18:54:35 +0900 To: David Conrad , Frank Ellermann From: Martin Duerst Subject: Re: [Ltru] Re: IANA XML registries In-Reply-To: References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello David, At 00:18 06/09/21, David Conrad wrote: >To clarify, the XML-ization of IANA registries is an _internal_ >effort, primarily aimed at allowing us to simplify/automate registry >creation and modification. We will take what efforts we can to >insure there is no significant change to the "legacy" registries. We >will _also_ publish the initial set of XML-ized registries (at >different URLs of course) and request comments. Assuming the initial >forays into XML-ization are deemed acceptable, we'll publish more. >If not (hey, it could happen), we'll not publish more (but we'll >still use the XML registries internally). Many thanks for this clarification, and also for helping with the discussions concerning the size of our new registry and possible consequences of this size. The main reason that you got contacted was that to some extent, we were considering to move from what could be called a 'home-brewn' format to something XML-based. One argument for it was that there was a rumor that IANA would be moving to XML, which you now have confirmed. Given that above, you describe the purpose of XML as mainly internal, I'm wondering whether, in your/IANAs view, an XML format defined by a WG would be: a) desirable (e.g. less work for IANA; helpful external input,...) b) irrelevant (the WG can do what they want, we'll do what we need,...) c) harmful (we'll have to re-do it anyway; it would confuse people,...) Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 05:55:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHL-0006rI-E7; Thu, 21 Sep 2006 05:55:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLHI-0006qh-R3 for ltru@ietf.org; Thu, 21 Sep 2006 05:55:32 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQLHC-0000AX-UN for ltru@ietf.org; Thu, 21 Sep 2006 05:55:32 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8L9tF35023420 for ; Thu, 21 Sep 2006 18:55:15 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 2a9c_48004e78_4957_11db_92f9_0014221fa3c9; Thu, 21 Sep 2006 18:55:15 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:54217) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 21 Sep 2006 18:55:17 +0900 Message-Id: <6.0.0.20.2.20060921182425.09d3a8b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 21 Sep 2006 18:28:23 +0900 To: David Conrad , John Cowan From: Martin Duerst Subject: Re: [Ltru] IANA XML registries In-Reply-To: References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello David, At 02:52 06/09/21, David Conrad wrote: >Internally, we use subversion for version control. It would be >relatively straight forward for us to provide an opt-in mailing list >that broadcasts the contextual diffs of any registry update. We can, >of course, also look at other alternatives people might suggest. If you use subversion internally already, the best way to allow differential updates would be to make subversion available publicly. I understand that it would have to be considered carefully, but it's really the protocol designed for the job. Also, as an alternative to mail broadcasts, I'd suggest using Atom (RFC 4287). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru t) with SMTP id k8L9tF35023420 for ; Thu, 21 Sep 2006 18:55:15 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 2a9c_48004e78_4957_11db_92f9_0014221fa3c9; Thu, 21 Sep 2006 18:55:15 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:54217) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 21 Sep 2006 18:55:17 +0900 Message-Id: <6.0.0.20.2.20060921182425.09d3a8b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 21 Sep 2006 18:28:23 +0900 To: David Conrad , John Cowan From: Martin Duerst Subject: Re: [Ltru] IANA XML registries In-Reply-To: References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello David, At 02:52 06/09/21, David Conrad wrote: >Internally, we use subversion for version control. It would be >relatively straight forward for us to provide an opt-in mailing list >that broadcasts the contextual diffs of any registry update. We can, >of course, also look at other alternatives people might suggest. If you use subversion internally already, the best way to allow differential updates would be to make subversion available publicly. I understand that it would have to be considered carefully, but it's really the protocol designed for the job. Also, as an alternative to mail broadcasts, I'd suggest using Atom (RFC 4287). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru t) with SMTP id k8L9tF35023420 for ; Thu, 21 Sep 2006 18:55:15 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 2a9c_48004e78_4957_11db_92f9_0014221fa3c9; Thu, 21 Sep 2006 18:55:15 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:54217) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 21 Sep 2006 18:55:17 +0900 Message-Id: <6.0.0.20.2.20060921182425.09d3a8b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 21 Sep 2006 18:28:23 +0900 To: David Conrad , John Cowan From: Martin Duerst Subject: Re: [Ltru] IANA XML registries In-Reply-To: References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello David, At 02:52 06/09/21, David Conrad wrote: >Internally, we use subversion for version control. It would be >relatively straight forward for us to provide an opt-in mailing list >that broadcasts the contextual diffs of any registry update. We can, >of course, also look at other alternatives people might suggest. If you use subversion internally already, the best way to allow differential updates would be to make subversion available publicly. I understand that it would have to be considered carefully, but it's really the protocol designed for the job. Also, as an alternative to mail broadcasts, I'd suggest using Atom (RFC 4287). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 09:23:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOWS-0007ew-3a; Thu, 21 Sep 2006 09:23:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOWR-0007er-G2 for ltru@ietf.org; Thu, 21 Sep 2006 09:23:23 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQOWG-0002RH-5s for ltru@ietf.org; Thu, 21 Sep 2006 09:23:23 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060921132311.VDMS25133.mta11.adelphia.net@DGBP7M81>; Thu, 21 Sep 2006 09:23:11 -0400 Message-ID: <010b01c6dd81$16640090$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <007501c6dd3f$04adb950$6401a8c0@DGBP7M81> <20060921130726.GI32052@ccil.org> Subject: Re: [Ltru] IANA XML registries Date: Thu, 21 Sep 2006 06:23:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >> Since the initial rollout of the Language Subtag Registry dated >> 2005-10-16, there have been 8 updates (including one just today, on >> 2006-09-20), for an average of one update every 8 weeks. > > However, there are only 31 distinct "Added:" dates in the whole > registry going back to 1995, which is really what counts from the > frequency-of-updates point of view. Even if we add thousands of items > at once, that's *one* update. I was answering Debbie's specific question about the past 12 months. I agree that this period has been unusually busy, with the increased attention on language tags spurred by the development and release of RFC 4646, and that this rate of change probably won't continue indefinitely (though my crystal ball works poorly at 6:20 am). -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 09:30:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOd2-0003Gn-J0; Thu, 21 Sep 2006 09:30:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOd1-0003GT-5Q for ltru@ietf.org; Thu, 21 Sep 2006 09:30:11 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQOcx-00044F-Ti for ltru@ietf.org; Thu, 21 Sep 2006 09:30:11 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GQOIs-0006k0-GM; Thu, 21 Sep 2006 09:09:22 -0400 Date: Thu, 21 Sep 2006 09:09:22 -0400 To: Martin Duerst Subject: Re: [Ltru] IANA XML registries Message-ID: <20060921130922.GJ32052@ccil.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> <6.0.0.20.2.20060921180422.09d3b6c0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060921180422.09d3b6c0@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > My personal opinion is that the HTTP mechanisms are best, > because already widely implemented. In addition to the two > mechanisms mentioned (HEAD, If-Modified-Since), there are also > Etags (hash values that can be used to check for changes) and > I seem to remember that there is also some diff mechanism > (I guess from WebDAV, Lisa?). Well, except for the last we already have those things; there's nothing to do (ergo nothing to discuss). The question for discussion is, what else if anything should we do? -- John Cowan cowan@ccil.org http://ccil.org/~cowan And now here I was, in a country where a right to say how the country should be governed was restricted to six persons in each thousand of its population. For the nine hundred and ninety-four to express dissatisfaction with the regnant system and propose to change it, would have made the whole six shudder as one man, it would have been so disloyal, so dishonorable, such putrid black treason. --Mark Twain's Connecticut Yankee _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 09:30:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOcz-0003G0-AB; Thu, 21 Sep 2006 09:30:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOcx-0003Fr-P4 for ltru@ietf.org; Thu, 21 Sep 2006 09:30:07 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQOct-00044F-EW for ltru@ietf.org; Thu, 21 Sep 2006 09:30:07 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GQOQJ-000722-QS for ltru@ietf.org; Thu, 21 Sep 2006 09:17:03 -0400 Date: Thu, 21 Sep 2006 09:07:26 -0400 To: Doug Ewell Subject: Re: [Ltru] IANA XML registries Message-ID: <20060921130726.GI32052@ccil.org> References: <007501c6dd3f$04adb950$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-asciFrom ltru-bounces@ietf.org Thu Sep 21 09:30:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOd2-0003Gn-J0; Thu, 21 Sep 2006 09:30:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOd1-0003GT-5Q for ltru@ietf.org; Thu, 21 Sep 2006 09:30:11 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQOcx-00044F-Ti for ltru@ietf.org; Thu, 21 Sep 2006 09:30:11 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GQOIs-0006k0-GM; Thu, 21 Sep 2006 09:09:22 -0400 Date: Thu, 21 Sep 2006 09:09:22 -0400 To: Martin Duerst Subject: Re: [Ltru] IANA XML registries Message-ID: <20060921130922.GJ32052@ccil.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> <6.0.0.20.2.20060921180422.09d3b6c0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060921180422.09d3b6c0@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > My personal opinion is that the HTTP mechanisms are best, > because already widely implemented. In addition to the two > mechanisms mentioned (HEAD, If-Modified-Since), there are also > Etags (hash values that can be used to check for changes) and > I seem to remember that there is also some diff mechanism > (I guess from WebDAV, Lisa?). Well, except for the last we already have those things; there's nothing to do (ergo nothing to discuss). The question for discussion is, what else if anything should we do? -- John Cowan cowan@ccil.org http://ccil.org/~cowan And now here I was, in a country where a right to say how the country should be governed was restricted to six persons in each thousand of its population. For the nine hundred and ninety-four to express dissatisfaction with the regnant system and propose to change it, would have made the whole six shudder as one man, it would have been so disloyal, so dishonorable, such putrid black treason. --Mark Twain's Connecticut Yankee _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 09:30:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOcz-0003G0-AB; Thu, 21 Sep 2006 09:30:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOcx-0003Fr-P4 for ltru@ietf.org; Thu, 21 Sep 2006 09:30:07 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQOct-00044F-EW for ltru@ietf.org; Thu, 21 Sep 2006 09:30:07 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GQOQJ-000722-QS for ltru@ietf.org; Thu, 21 Sep 2006 09:17:03 -0400 Date: Thu, 21 Sep 2006 09:07:26 -0400 To: Doug Ewell Subject: Re: [Ltru] IANA XML registries Message-ID: <20060921130726.GI32052@ccil.org> References: <007501c6dd3f$04adb950$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007501c6dd3f$04adb950$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i Resent-From: cowan@ccil.org Resent-Date: Thu, 21 Sep 2006 09:17:03 -0400 Resent-To: ltru@ietf.org Resent-Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@iana.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > Since the initial rollout of the Language Subtag Registry dated > 2005-10-16, there have been 8 updates (including one just today, on > 2006-09-20), for an average of one update every 8 weeks. However, there are only 31 distinct "Added:" dates in the whole registry going back to 1995, which is really what counts from the frequency-of- updates point of view. Even if we add thousands of items at once, that's *one* update. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Heckler: "Go on, Al, tell 'em all you know. It won't take long." Al Smith: "I'll tell 'em all we *both* know. It won't take any longer." _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru i Content-Disposition: inline In-Reply-To: <007501c6dd3f$04adb950$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i Resent-From: cowan@ccil.org Resent-Date: Thu, 21 Sep 2006 09:17:03 -0400 Resent-To: ltru@ietf.org Resent-Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@iana.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > Since the initial rollout of the Language Subtag Registry dated > 2005-10-16, there have been 8 updates (including one just today, on > 2006-09-20), for an average of one update every 8 weeks. However, there are only 31 distinct "Added:" dates in the whole registry going back to 1995, which is really what counts from the frequency-of- updates point of view. Even if we add thousands of items at once, that's *one* update. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Heckler: "Go on, Al, tell 'em all you know. It won't take long." Al Smith: "I'll tell 'em all we *both* know. It won't take any longer." _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 09:51:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOxj-0007es-Ib; Thu, 21 Sep 2006 09:51:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOxh-0007bT-QH for ltru@ietf.org; Thu, 21 Sep 2006 09:51:33 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQOxE-0001J7-V5 for ltru@ietf.org; Thu, 21 Sep 2006 09:51:33 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GQOxE-0008Of-Kk; Thu, 21 Sep 2006 09:51:04 -0400 Date: Thu, 21 Sep 2006 09:51:04 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: IANA XML registries Message-ID: <20060921135104.GL32052@ccil.org> References: <00b101c6dd43$4e9ae840$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b101c6dd43$4e9ae840$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > I can't speak for anyone else, but it helps me quite a bit that the > records are grouped by type. I'd be opposed to changing this. In fact, > I'd want to go the other way, tighting up Section 5.1 to require subtags > to be in alphabetical order, and further splitting the "language" > subtags into 2-letter and 3-letter subgroups and putting "anp" and "frr" > back in the 3-letter subgroup. I'd be opposed to any more strictures on ordering; by its nature, record-jar is supposed to carry all relevant information in the tags and not "care" about the order of records. A megabyte isn't very big these days: there's no reason not to read it into a data structure of your choice and sort it however you want. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Sound change operates regularly to produce irregularities; analogy operates irregularly to produce regularities. --E.H. Sturtevant, ca. 1945, probably at Yale _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 09:58:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQP3y-0003Ny-6m; Thu, 21 Sep 2006 09:58:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQP3w-0003Mn-9O for ltru@ietf.org; Thu, 21 Sep 2006 09:58:00 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQP3Z-0002V6-GD for ltru@ietf.org; Thu, 21 Sep 2006 09:58:00 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060921135736.JKJB17675.mta9.adelphia.net@DGBP7M81>; Thu, 21 Sep 2006 09:57:36 -0400 Message-ID: <012301c6dd85$e5699a90$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <00b101c6dd43$4e9ae840$6401a8c0@DGBP7M81> <20060921135104.GL32052@ccil.org> Subject: Re: [Ltru] Re: IANA XML registries Date: Thu, 21 Sep 2006 06:57:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > I'd be opposed to any more strictures on ordering; by its nature, > record-jar is supposed to carry all relevant information in the tags > and not "care" about the order of records. A megabyte isn't very big > these days: there's no reason not to read it into a data structure of > your choice and sort it however you want. It helps my eyeballs, not my programs. I have to re-sort the Registry by description anyway when I build my cooked version. I won't pursue this sorting issue, but I will put all the new 639-3-based subtags in alpha order. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 10:29:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQPXm-0004cZ-Lm; Thu, 21 Sep 2006 10:28:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQPXj-0004SM-Pp for ltru@ietf.org; Thu, 21 Sep 2006 10:28:47 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQPUZ-0007pp-54 for ltru@ietf.org; Thu, 21 Sep 2006 10:25:35 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060921142530.DUNK14728.mta10.adelphia.net@DGBP7M81> for ; Thu, 21 Sep 2006 10:25:30 -0400 Message-ID: <013301c6dd89$cadbfa70$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 21 Sep 2006 07:25:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ltru] Re: IANA XML registries X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > If you use subversion internally already, the best way to allow > differential updates would be to make subversion available publicly. If they use subversion, wouldn't that be subversive? Sorry, I'll leave now. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 16:50:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQVUb-0000bm-Ro; Thu, 21 Sep 2006 16:49:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQVUa-0000bg-AP for ltru@ietf.org; Thu, 21 Sep 2006 16:49:56 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQVUY-00056V-Vf for ltru@ietf.org; Thu, 21 Sep 2006 16:49:56 -0400 Received: from terminus.local (dhcp-37-248.icann.org [192.0.37.248]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id k8LKoIN2024049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Sep 2006 13:50:19 -0700 Received: from [127.0.0.1] by terminus.local (PGP Universal service); Thu, 21 Sep 2006 13:49:33 -0700 X-PGP-Universal: processed; by terminus.local on Thu, 21 Sep 2006 13:49:33 -0700 In-Reply-To: <006f01c6dd3d$9ed60ed0$6401a8c0@DGBP7M81> References: <008601c6dbf6$8238dc00$6401a8c0@DGBP7M81> <451006C2.60603@yahoo-inc.com> <004301c6dc6d$bebab190$6401a8c0@DGBP7M81> <969B72EA-3C02-4132-9B63-DCD1156E5C6C@icann.org> <006f01c6dd3d$9ed60ed0$6401a8c0@DGBP7M81> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: From: David Conrad Subject: Re: [Ltru] Re: zh-hakka Date: Thu, 21 Sep 2006 13:49:32 -0700 To: Doug Ewell X-Mailer: Apple Mail (2.752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug, On Sep 20, 2006, at 10:20 PM, Doug Ewell wrote: > I'm sure you won't mind some extra pairs of eyes to help maintain a > high standard of quality. Not at all. On the contrary, the more the merrier... Rgds, -drc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 18:38:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQXBW-0006nu-N8; Thu, 21 Sep 2006 18:38:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQXBV-0006kk-MM for ltru@ietf.org; Thu, 21 Sep 2006 18:38:21 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQXBU-0007LA-5n for ltru@ietf.org; Thu, 21 Sep 2006 18:38:21 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004746438.msg for ; Thu, 21 Sep 2006 23:39:22 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 21 Sep 2006 23:37:46 +0100 From: "Debbie Garside" To: , "'LTRU Working Group'" , Subject: RE: [Ltru] Re: zh-hakka Date: Thu, 21 Sep 2006 23:37:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <006f01c6dd3d$9ed60ed0$6401a8c0@DGBP7M81> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 thread-index: AcbdPgZMIq8Cix6OSXOs+SBoudbJ1QAjZBpw Message-ID: <63B577DE25954A46B14E5B1127C1FAE6.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Thu, 21 Sep 2006 23:39:22 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Thu, 21 Sep 2006 23:39:22 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: 'Frank Ellermann' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org David Conran wrote: > >> possibilities are SP and ME, so let's assume that for now. Frank wrote: > > > > Actually, I believe they're planning on proposing RS for Serbia... > Doug wrote: > I know the Serbian government proposed RS (for "Republic of > Serbia"), and I've heard alternatively that ISO (a) supports > it or (b) opposes it because of their policy against using > words like "Republic" to make the code element. I guess we > won't know for sure until the formal announcement. In any > case, I was just using it for illustration. Unofficial Country Code Info: RS/SRB for Serbia ME/MNE for Montenegro I would expect a newsletter to be published within the next 4-5 weeks displaying the official results. I don't expect there to be any changes but it isn't official until the voting is over and the Newsletter published! Best regards Debbie > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: 21 September 2006 06:20 > To: LTRU Working Group > Cc: Frank Ellermann > Subject: Re: [Ltru] Re: zh-hakka > > David Conrad wrote: > > >> IANA is not perfect. > > > > Indeed. We apologize for any errors that might have > cropped up during > > IANA processing of registry modification requests and we'd be very > > interested in working with interested parties in improving our > > processes such that those errors aren't repeated (this is > one of the > > reasons why we're doing the internal XMLization -- it > enables simpler > > automation the registry modifications). > > No problem. I'm sure you won't mind some extra pairs of eyes > to help maintain a high standard of quality. (BTW, the new > 2006-09-20 version of the Registry looks great.) > > >> In the next few weeks, or months or something, ISO 3166/MA will > >> decide on new alpha-2 code elements for Serbia and for Montenegro, > >> now that they have agreed to break up. I don't have any inside > >> knowledge on what the code elements will be, but two > widely reported > >> possibilities are SP and ME, so let's assume that for now. > > > > Actually, I believe they're planning on proposing RS for Serbia... > > I know the Serbian government proposed RS (for "Republic of > Serbia"), and I've heard alternatively that ISO (a) supports > it or (b) opposes it because of their policy against using > words like "Republic" to make the code element. I guess we > won't know for sure until the formal announcement. In any > case, I was just using it for illustration. > > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > RFC 4645 * UTN #14 > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 19:21:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQXrg-0003hV-RZ; Thu, 21 Sep 2006 19:21:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQXrf-0003hQ-JE for ltru@lists.ietf.org; Thu, 21 Sep 2006 19:21:55 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQXre-0005BH-79 for ltru@lists.ietf.org; Thu, 21 Sep 2006 19:21:55 -0400 Received: from terminus.local (dhcp-37-248.icann.org [192.0.37.248]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id k8LNMRRD024587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Sep 2006 16:22:27 -0700 Received: from [127.0.0.1] by terminus.local (PGP Universal service); Thu, 21 Sep 2006 16:21:42 -0700 X-PGP-Universal: processed; by terminus.local on Thu, 21 Sep 2006 16:21:42 -0700 In-Reply-To: <6.0.0.20.2.20060921183415.0368dd00@localhost> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> <6.0.0.20.2.20060921183415.0368dd00@localhost> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <1D0B84FC-6772-4CCE-89B9-C5968AE0B5FD@icann.org> From: David Conrad Subject: Re: [Ltru] Re: IANA XML registries Date: Thu, 21 Sep 2006 16:21:40 -0700 To: Martin Duerst X-Mailer: Apple Mail (2.752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin, On Sep 21, 2006, at 2:54 AM, Martin Duerst wrote: > Given that above, you describe the purpose of XML as mainly internal, > I'm wondering whether, in your/IANAs view, an XML format defined by > a WG would be: > > a) desirable (e.g. less work for IANA; helpful external input,...) > b) irrelevant (the WG can do what they want, we'll do what we > need,...) > c) harmful (we'll have to re-do it anyway; it would confuse > people,...) I'd say "a". I'm all in favor of less work for IANA... :-) More seriously, as far as I'm aware, there is no real specification on how registries must be created, so if a WG decides to go to the trouble to define a registry using XML (and it doesn't break anything at IANA), we'd probably just use that definition. However, I should note that the registry XMLization project is something done by IANA primarily for IANA and has neither been requested (to my knowledge) nor reviewed by the IESG or IAB. We will be providing access to the XML registries, but if the IETF community decides we should publish registries in some other fashion, we'd have to translate the work you all (and we) did. Not that I think that would happen... Rgds, -drc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 23:17:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQbXn-0007G9-5g; Thu, 21 Sep 2006 23:17:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQbXl-0007G4-A1 for ltru@lists.ietf.org; Thu, 21 Sep 2006 23:17:37 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQbXh-0007Qi-Eo for ltru@lists.ietf.org; Thu, 21 Sep 2006 23:17:37 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8M3HRmf000053 for ; Fri, 22 Sep 2006 12:17:28 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 42ee_e01b2e26_49e8_11db_8392_0014221fa3c9; Fri, 22 Sep 2006 12:17:27 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49610) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 22 Sep 2006 12:17:30 +0900 Message-Id: <6.0.0.20.2.20060922121257.07810740@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 22 Sep 2006 12:17:10 +0900 To: ltru@lists.ietf.org From: Martin Duerst In-Reply-To: <1D0B84FC-6772-4CCE-89B9-C5968AE0B5FD@icann.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> <6.0.0.20.2.20060921183415.0368dd00@localhost> <1D0B84FC-6772-4CCE-89B9-C5968AE0B5FD@icann.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [Ltru] To XML or not to XML X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear LTRU WG, We have earlier discussed whether we should move to XML or not for the registry. One unknown in these discussions was what was (or wasn't) going on at IANA. Thanks to David's help, we now have a much better idea of what IANA is up to. Given that information, I'd like us to make a firm decision on whether to use XML or not for RFC464xbis soon. Please (re)state your preference. Regards, Martin. At 08:21 06/09/22, David Conrad wrote: >Martin, > >On Sep 21, 2006, at 2:54 AM, Martin Duerst wrote: >> Given that above, you describe the purpose of XML as mainly internal, >> I'm wondering whether, in your/IANAs view, an XML format defined by >> a WG would be: >> >> a) desirable (e.g. less work for IANA; helpful external input,...) >> b) irrelevant (the WG can do what they want, we'll do what we >> need,...) >> c) harmful (we'll have to re-do it anyway; it would confuse >> people,...) > >I'd say "a". I'm all in favor of less work for IANA... :-) > >More seriously, as far as I'm aware, there is no real specification >on how registries must be created, so if a WG decides to go to the >trouble to define a registry using XML (and it doesn't break anything >at IANA), we'd probably just use that definition. > >However, I should note that the registry XMLization project is >something done by IANA primarily for IANA and has neither been >requested (to my knowledge) nor reviewed by the IESG or IAB. We will >be providing access to the XML registries, but if the IETF community >decides we should publish registries in some other fashion, we'd have >to translate the work you all (and we) did. Not that I think that >would happen... > >Rgds, >-drc > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 23:23:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQbdE-0002bB-4x; Thu, 21 Sep 2006 23:23:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQbdD-0002XN-CN for ltru@ietf.org; Thu, 21 Sep 2006 23:23:15 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQbdC-0008O8-6k for ltru@ietf.org; Thu, 21 Sep 2006 23:23:15 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GQbdB-00041i-Rd; Thu, 21 Sep 2006 23:23:13 -0400 Date: Thu, 21 Sep 2006 23:23:13 -0400 To: Debbie Garside Message-ID: <20060922032313.GR32052@ccil.org> References: <006f01c6dd3d$9ed60ed0$6401a8c0@DGBP7M81> <63B577DE25954A46B14E5B1127C1FAE6.MAI@home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63B577DE25954A46B14E5B1127C1FAE6.MAI@home> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ltru@ietf.org Subject: [Ltru] RS region subtag X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside scripsit: > RS/SRB for Serbia Well, let's hope that Republika Srpska (currently part of Bosnia) never becomes a separate country. -- Real FORTRAN programmers can program FORTRAN John Cowan in any language. --Allen Brown cowan@ccil.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 21 23:32:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQbm2-0006UQ-Jj; Thu, 21 Sep 2006 23:32:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQbm1-0006UL-4k for ltru@lists.ietf.org; Thu, 21 Sep 2006 23:32:21 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQblz-0001ZT-NF for ltru@lists.ietf.org; Thu, 21 Sep 2006 23:32:21 -0400 Received: from [10.72.66.13] (snvvpn-10-72-66-c13.corp.yahoo.com [10.72.66.13]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8M3WDdL040097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Sep 2006 20:32:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=zyvx5dUTWitsXBAjrHKudEhD5PE+/3eWlxssStKd1WaxQBUFgGWUZQkejdKlP4NW Message-ID: <4513593C.4070201@yahoo-inc.com> Date: Thu, 21 Sep 2006 20:32:12 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] To XML or not to XML References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> <6.0.0.20.2.20060921183415.0368dd00@localhost> <1D0B84FC-6772-4CCE-89B9-C5968AE0B5FD@icann.org> <6.0.0.20.2.20060922121257.07810740@localhost> In-Reply-To: <6.0.0.20.2.20060922121257.07810740@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org My preference: -1 to XML While I think XML would have been a better choice 'ab initio', changing the file format strikes me as a "no benefit" change, with plenty of pointless risk. Other IANA registries apparently are not as well-specified as ours. While I was a (if not *the*) proponent for XML originally, changing now will require substantial, pointless change to our documents. I would support providing an additional, non-normative, copy of the registry using an XML format. Addison Martin Duerst wrote: > Dear LTRU WG, > > We have earlier discussed whether we should move to XML or not > for the registry. One unknown in these discussions was what > was (or wasn't) going on at IANA. > > Thanks to David's help, we now have a much better idea of > what IANA is up to. Given that information, I'd like us to > make a firm decision on whether to use XML or not for RFC464xbis > soon. Please (re)state your preference. > > Regards, Martin. > > At 08:21 06/09/22, David Conrad wrote: >> Martin, >> >> On Sep 21, 2006, at 2:54 AM, Martin Duerst wrote: >>> Given that above, you describe the purpose of XML as mainly internal, >>> I'm wondering whether, in your/IANAs view, an XML format defined by >>> a WG would be: >>> >>> a) desirable (e.g. less work for IANA; helpful external input,...) >>> b) irrelevant (the WG can do what they want, we'll do what we >>> need,...) >>> c) harmful (we'll have to re-do it anyway; it would confuse >>> people,...) >> I'd say "a". I'm all in favor of less work for IANA... :-) >> >> More seriously, as far as I'm aware, there is no real specification >> on how registries must be created, so if a WG decides to go to the >> trouble to define a registry using XML (and it doesn't break anything >> at IANA), we'd probably just use that definition. >> >> However, I should note that the registry XMLization project is >> something done by IANA primarily for IANA and has neither been >> requested (to my knowledge) nor reviewed by the IESG or IAB. We will >> be providing access to the XML registries, but if the IETF community >> decides we should publish registries in some other fashion, we'd have >> to translate the work you all (and we) did. Not that I think that >> would happen... >> >> Rgds, >> -drc >> > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 01:27:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQdZh-0006d9-T7; Fri, 22 Sep 2006 01:27:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQdZg-0006d4-RS for ltru@ietf.org; Fri, 22 Sep 2006 01:27:44 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQdZf-0003M1-Jz for ltru@ietf.org; Fri, 22 Sep 2006 01:27:44 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060922052740.KEHL17675.mta9.adelphia.net@DGBP7M81> for ; Fri, 22 Sep 2006 01:27:40 -0400 Message-ID: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 21 Sep 2006 22:27:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Ltru] Re: To XML or not to XML X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > We have earlier discussed whether we should move to XML or not for the > registry. One unknown in these discussions was what was (or wasn't) > going on at IANA. > > Thanks to David's help, we now have a much better idea of what IANA is > up to. Given that information, I'd like us to make a firm decision on > whether to use XML or not for RFC464xbis soon. Please (re)state your > preference. My preference is: 0 That is to say, neither +1 nor -1. I see advantages and disadvantages to either sticking with record-jar or switching to XML. I'm happy to let the rest of the group decide one way or the other, and I'll build RFC 4645bis accordingly. (It should go without saying that switching to any format OTHER than XML would be a colossal mistake.) -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 02:52:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQetj-0008JN-M1; Fri, 22 Sep 2006 02:52:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQeti-0008JI-Nh for ltru@ietf.org; Fri, 22 Sep 2006 02:52:30 -0400 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQeta-0002VH-H6 for ltru@ietf.org; Fri, 22 Sep 2006 02:52:30 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id E7CC1472E; Fri, 22 Sep 2006 15:52:05 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31323-04; Fri, 22 Sep 2006 15:52:05 +0900 (JST) Received: from webmail.w3.mag.keio.ac.jp (toro [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id A49F3460D; Fri, 22 Sep 2006 15:52:05 +0900 (JST) Received: from 61.112.211.238 (SquirrelMail authenticated user fsasaki) by webmail.w3.mag.keio.ac.jp with HTTP; Fri, 22 Sep 2006 15:52:05 +0900 (JST) Message-ID: <2227.61.112.211.238.1158907925.squirrel@webmail.w3.mag.keio.ac.jp> In-Reply-To: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> References: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> Date: Fri, 22 Sep 2006 15:52:05 +0900 (JST) Subject: Re: [Ltru] Re: To XML or not to XML From: "Felix Sasaki" To: "Doug Ewell" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-2022-jp X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fsasaki@w3.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > Martin Duerst wrote: > >> We have earlier discussed whether we should move to XML or not for the >> registry. One unknown in these discussions was what was (or wasn't) >> going on at IANA. >> >> Thanks to David's help, we now have a much better idea of what IANA is >> up to. Given that information, I'd like us to make a firm decision on >> whether to use XML or not for RFC464xbis soon. Please (re)state your >> preference. > > My preference is: > > 0 > > That is to say, neither +1 nor -1. I see advantages and disadvantages > to either sticking with record-jar or switching to XML. Addison proposed "-1 to XML", while also stating that he would be fine with a *non-normative* XML representation. My impression is that your "0" is not incompatible to Addisons view - am I right? > I'm happy to > let the rest of the group decide one way or the other, and I'll build > RFC 4645bis accordingly. I agree with Addisons proposal and also hope that the group adopts *one* non-normative XML format. Otherwise different people outside this group might just go ahead and create multiple XML representations for the same purpose. Felix > > (It should go without saying that switching to any format OTHER than XM= L > would be a colossal mistake.) > > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > RFC 4645 * UTN #14 > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 03:13:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQfDm-00088Q-MZ; Fri, 22 Sep 2006 03:13:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQfDk-00088K-Uq for ltru@lists.ietf.org; Fri, 22 Sep 2006 03:13:12 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQfDh-0005VY-Kp for ltru@lists.ietf.org; Fri, 22 Sep 2006 03:13:12 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id D5DD826C158; Fri, 22 Sep 2006 09:12:54 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id DC4F326C126; Fri, 22 Sep 2006 09:12:53 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id D96F858ED17; Fri, 22 Sep 2006 09:12:53 +0200 (CEST) Date: Fri, 22 Sep 2006 09:12:53 +0200 From: Stephane Bortzmeyer To: Martin Duerst Message-ID: <20060922071253.GA28368@nic.fr> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> <6.0.0.20.2.20060921183415.0368dd00@localhost> <1D0B84FC-6772-4CCE-89B9-C5968AE0B5FD@icann.org> <6.0.0.20.2.20060922121257.07810740@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060922121257.07810740@localhost> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@lists.ietf.org Subject: [Ltru] Re: To XML or not to XML X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, Sep 22, 2006 at 12:17:10PM +0900, Martin Duerst wrote a message of 55 lines which said: > Given that information, I'd like us to make a firm decision on > whether to use XML or not for RFC464xbis soon. Please (re)state your > preference. My humble vote goes to XML for the following reasons (in order of *decreasing* strength): * in the long term (registries last a long time), XML is a safe bet, * XML makes easy to produce tools to process and *check* the registry, thanks to schema languages like RelaxNG or Schematron, * there are a lot of tools, libraries, editors, etc for XML, for every programming language and every licence, * there are a lot of experience, knowledge and documentation for XML, * it is better to stay in synch with IANA. PS: the way the survey is casted is strange. People should be requested to state a preference to a specific technology (XML, JSON, YAML, record-jar, CSV) not just "XML or not" because "not XML" would leave a lot of things to discuss. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 03:16:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQfGu-0000EY-51; Fri, 22 Sep 2006 03:16:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQfGs-0000EN-DC for ltru@lists.ietf.org; Fri, 22 Sep 2006 03:16:26 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQfGr-0006O3-4c for ltru@lists.ietf.org; Fri, 22 Sep 2006 03:16:26 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id B87B126C126; Fri, 22 Sep 2006 09:16:24 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 08C0D26C110; Fri, 22 Sep 2006 09:16:24 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 0457058ED17; Fri, 22 Sep 2006 09:16:24 +0200 (CEST) Date: Fri, 22 Sep 2006 09:16:23 +0200 From: Stephane Bortzmeyer To: Addison Phillips Message-ID: <20060922071623.GB28368@nic.fr> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> <6.0.0.20.2.20060921183415.0368dd00@localhost> <1D0B84FC-6772-4CCE-89B9-C5968AE0B5FD@icann.org> <6.0.0.20.2.20060922121257.07810740@localhost> <4513593C.4070201@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4513593C.4070201@yahoo-inc.com> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: To XML or not to XML X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Thu, Sep 21, 2006 at 08:32:12PM -0700, Addison Phillips wrote a message of 83 lines which said: > Other IANA registries apparently are not as well-specified as ours. Since it seems a criticism, I want to emphasize what Frank Ellermann already said: most other registries do not have to be well-specified. They are extremely simple, with mostly just pairs "attribute: value". They do not have structured values with integrity constraints. That's one of the reasons why nobody (to my limited knowledge) before LTRU had the issue. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 03:26:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQfQ9-0004bQ-Uc; Fri, 22 Sep 2006 03:26:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQfQ8-0004an-EI for ltru@lists.ietf.org; Fri, 22 Sep 2006 03:26:00 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQfQ7-00083J-3L for ltru@lists.ietf.org; Fri, 22 Sep 2006 03:26:00 -0400 Received: from [10.72.66.13] (snvvpn-10-72-66-c13.corp.yahoo.com [10.72.66.13]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8M7PrGj048266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Sep 2006 00:25:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=on1R9AR/X/YM1U8KgqnDhUJ0W9WeX9+b8ud1050426ZFeOroDVHqpLbESMmIQPDD Message-ID: <45139000.4060709@yahoo-inc.com> Date: Fri, 22 Sep 2006 00:25:52 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> <6.0.0.20.2.20060921183415.0368dd00@localhost> <1D0B84FC-6772-4CCE-89B9-C5968AE0B5FD@icann.org> <6.0.0.20.2.20060922121257.07810740@localhost> <4513593C.4070201@yahoo-inc.com> <20060922071623.GB28368@nic.fr> In-Reply-To: <20060922071623.GB28368@nic.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: To XML or not to XML X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > On Thu, Sep 21, 2006 at 08:32:12PM -0700, > Addison Phillips wrote > a message of 83 lines which said: > >> Other IANA registries apparently are not as well-specified as ours. > > Since it seems a criticism, I want to emphasize what Frank Ellermann That isn't really my point: I don't mean it as a criticism. I just mean to point out that IANA is free to change the formats of other registries, as it is NOT free to do with LTRU. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 03:26:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQfQt-0004jg-03; Fri, 22 Sep 2006 03:26:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQfQs-0004jb-Cq for ltru@ietf.org; Fri, 22 Sep 2006 03:26:46 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQfQr-0008HP-3N for ltru@ietf.org; Fri, 22 Sep 2006 03:26:46 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 8844026C110; Fri, 22 Sep 2006 09:26:44 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 956DC26C173; Fri, 22 Sep 2006 09:26:39 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 925BB58ED17; Fri, 22 Sep 2006 09:26:39 +0200 (CEST) Date: Fri, 22 Sep 2006 09:26:39 +0200 From: Stephane Bortzmeyer To: Felix Sasaki Message-ID: <20060922072639.GD28368@nic.fr> References: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> <2227.61.112.211.238.1158907925.squirrel@webmail.w3.mag.keio.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2227.61.112.211.238.1158907925.squirrel@webmail.w3.mag.keio.ac.jp> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Doug Ewell , LTRU Working Group Subject: [Ltru] Re: To XML or not to XML X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, Sep 22, 2006 at 03:52:05PM +0900, Felix Sasaki wrote a message of 57 lines which said: > I agree with Addisons proposal and also hope that the group adopts > *one* non-normative XML format. Otherwise different people outside > this group might just go ahead and create multiple XML > representations for the same purpose. +1 Two proposals have been made and discussed. http://www1.ietf.org/mail-archive/web/ltru/current/msg05566.html http://www1.ietf.org/mail-archive/web/ltru/current/msg05604.html Opinions are welcome about: * Schema language to use (Frank used DTD, I used RelaxNG), * "elements or attributes", the old XML thread :-) * names for the elements: follow the RFC or not? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 03:49:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQfmT-0005qY-ET; Fri, 22 Sep 2006 03:49:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQfmS-0005qT-8n for ltru@ietf.org; Fri, 22 Sep 2006 03:49:04 -0400 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQfmQ-0004k3-Lt for ltru@ietf.org; Fri, 22 Sep 2006 03:49:04 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 6AF994715; Fri, 22 Sep 2006 16:49:02 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31854-05; Fri, 22 Sep 2006 16:49:02 +0900 (JST) Received: from webmail.w3.mag.keio.ac.jp (toro [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 28422463D; Fri, 22 Sep 2006 16:49:02 +0900 (JST) Received: from 61.112.211.238 (SquirrelMail authenticated user fsasaki) by webmail.w3.mag.keio.ac.jp with HTTP; Fri, 22 Sep 2006 16:49:02 +0900 (JST) Message-ID: <2355.61.112.211.238.1158911342.squirrel@webmail.w3.mag.keio.ac.jp> In-Reply-To: <20060922072639.GD28368@nic.fr> References: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> <2227.61.112.211.238.1158907925.squirrel@webmail.w3.mag.keio.ac.jp> <20060922072639.GD28368@nic.fr> Date: Fri, 22 Sep 2006 16:49:02 +0900 (JST) From: "Felix Sasaki" To: "Stephane Bortzmeyer" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-2022-jp X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: LTRU Working Group Subject: [Ltru] Re: To XML or not to XML X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fsasaki@w3.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > On Fri, Sep 22, 2006 at 03:52:05PM +0900, > Felix Sasaki wrote > a message of 57 lines which said: > >> I agree with Addisons proposal and also hope that the group adopts >> *one* non-normative XML format. Otherwise different people outside >> this group might just go ahead and create multiple XML >> representations for the same purpose. > > +1 > > Two proposals have been made and discussed. > > http://www1.ietf.org/mail-archive/web/ltru/current/msg05566.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg05604.html > > Opinions are welcome about: > > * Schema language to use (Frank used DTD, I used RelaxNG), I would prefer either RELAX NG, since you can generate XML DTD / XML Schema out of it easliy. > * "elements or attributes", the old XML thread :-) I would follow the comments from Martin in the thread on this list. > * names for the elements: follow the RFC or not? For further discussion on the topic, I would propose: 1) to wait until further comments come in or at least our co-chairs revie= w the discussion and see if the +1 above is really the way to go, and 2) to consider if we really want to use the bandwith of this group for th= e discussion, since it would be a non-normative representation. To avoid getting on many people nerves, it might be better to create the representation with only the really interested parties. Of course, the group should look at and endorse the result. Felix _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 07:02:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQinq-0004UJ-UL; Fri, 22 Sep 2006 07:02:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQinq-0004U4-Co for ltru@lists.ietf.org; Fri, 22 Sep 2006 07:02:42 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQino-000670-HQ for ltru@lists.ietf.org; Fri, 22 Sep 2006 07:02:42 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8MB2SX0011437 for ; Fri, 22 Sep 2006 20:02:28 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 43c6_d5f992ac_4a29_11db_82f6_0014221fa3c9; Fri, 22 Sep 2006 20:02:27 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:46512) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 22 Sep 2006 20:02:30 +0900 Message-Id: <6.0.0.20.2.20060922170556.0781a350@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 22 Sep 2006 17:10:24 +0900 To: Stephane Bortzmeyer From: Martin Duerst In-Reply-To: <20060922071253.GA28368@nic.fr> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> <6.0.0.20.2.20060921183415.0368dd00@localhost> <1D0B84FC-6772-4CCE-89B9-C5968AE0B5FD@icann.org> <6.0.0.20.2.20060922121257.07810740@localhost> <20060922071253.GA28368@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: To XML or not to XML (Clarification) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 16:12 06/09/22, Stephane Bortzmeyer wrote: >PS: the way the survey is casted is strange. People should be >requested to state a preference to a specific technology (XML, JSON, >YAML, record-jar, CSV) not just "XML or not" because "not XML" would >leave a lot of things to discuss. To clarify: - The survey is "Switch to XML or stay with record-jar" Details, including use of schema language, character encoding, and so on are left for later discussion. Other formats haven't been seriously proposed in this round, so I do not see the point of including them in this survey. Of course, if anybody wants to seriously propose a switch to something like JSON or YAML, they can do that separately (better sooner than later). - The survey is about the one official and normative format. This does neither include nor exclude additional non-normative formats. Hope this helps, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 07:02:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQinw-0004bQ-5m; Fri, 22 Sep 2006 07:02:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQinr-0004UR-BY for ltru@ietf.org; Fri, 22 Sep 2006 07:02:43 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQino-000674-HR for ltru@ietf.org; Fri, 22 Sep 2006 07:02:43 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8MB2TQx011442 for ; Fri, 22 Sep 2006 20:02:30 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 6e3b_d70c9aae_4a29_11db_978c_0014221f2a2d; Fri, 22 Sep 2006 20:02:29 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:46512) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 22 Sep 2006 20:02:30 +0900 Message-Id: <6.0.0.20.2.20060922171056.07816630@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 22 Sep 2006 17:13:52 +0900 To: John Cowan From: Martin Duerst Subject: Re: [Ltru] IANA XML registries In-Reply-To: <20060921130922.GJ32052@ccil.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> <6.0.0.20.2.20060921180422.09d3b6c0@localhost> <20060921130922.GJ32052@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 22:09 06/09/21, John Cowan wrote: >Martin Duerst scripsit: > >> My personal opinion is that the HTTP mechanisms are best, >> because already widely implemented. In addition to the two >> mechanisms mentioned (HEAD, If-Modified-Since), there are also >> Etags (hash values that can be used to check for changes) and >> I seem to remember that there is also some diff mechanism >> (I guess from WebDAV, Lisa?). > >Well, except for the last we already have those things; there's >nothing to do (ergo nothing to discuss). The question for >discussion is, what else if anything should we do? Setting up a file that contains only the date of the last change may need as much of an instruction to IANA as setting up a compressed version that can be content negotiated or a version that can be downloaded incrementally. HEAD and If-Modified-Since should indeed come for free with a decent Web server. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 07:02:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQinr-0004UN-14; Fri, 22 Sep 2006 07:02:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQinq-0004U5-Cr for ltru@ietf.org; Fri, 22 Sep 2006 07:02:42 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQino-000679-HQ for ltru@ietf.org; Fri, 22 Sep 2006 07:02:42 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8MB2VNF011445 for ; Fri, 22 Sep 2006 20:02:31 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 6e3d_d7ecbf3a_4a29_11db_8636_0014221f2a2d; Fri, 22 Sep 2006 20:02:30 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:46512) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 22 Sep 2006 20:02:32 +0900 Message-Id: <6.0.0.20.2.20060922171503.0782c6e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 22 Sep 2006 17:17:57 +0900 To: Addison Phillips , "'LTRU Working Group'" From: Martin Duerst Subject: Re: [Ltru] split section 3.1 In-Reply-To: <45101757.9020807@yahoo-inc.com> References: <45101757.9020807@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 01:14 06/09/20, Addison Phillips wrote: >To address the various comments on the length of Section 3.1, I have created an experimental version of draft-01 and posted it on my website. [chair hat off] Thanks, great. >I split the section into three sections: File Format, Record Definitions, and Field Requirements. That last is split up by field type. Some text rearrangement was necessary to make this work and a little bit of editing was done. The last section needs an introductory paragraph (yes, Martin, yes, I know :-) ) and a bit more tugging is necessary. To avoid the problems with four levels that Frank mentioned, one possibility is to flatten the current fields section (3.1.3) into a third-level section for each Field type. >However... I think it important to get a consensus that such a massive edit is called for (just to split the darned thing up a bit). I *personally* feel that this is something that should be left alone: we didn't do it in the 4646 era, why now? We always gain new insights and get smarter, or so we hope. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 08:14:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQjv7-0001UR-CI; Fri, 22 Sep 2006 08:14:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQjv6-0001UI-5T for ltru@lists.ietf.org; Fri, 22 Sep 2006 08:14:16 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQjv1-0002Dh-P2 for ltru@lists.ietf.org; Fri, 22 Sep 2006 08:14:16 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GQjuc-0006St-IL for ltru@lists.ietf.org; Fri, 22 Sep 2006 14:13:46 +0200 Received: from pd9fbad55.dip0.t-ipconnect.de ([217.251.173.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Sep 2006 14:13:46 +0200 Received: from nobody by pd9fbad55.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Sep 2006 14:13:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 22 Sep 2006 13:46:35 +0200 Organization: Lines: 10 Message-ID: <4513CD1B.352F@xyzzy.claranet.de> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> <6.0.0.20.2.20060921183415.0368dd00@localhost> <1D0B84FC-6772-4CCE-89B9-C5968AE0B5FD@icann.org> <6.0.0.20.2.20060922121257.07810740@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad55.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] Re: To XML or not to XML X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > Please (re)state your preference. NCRs => record-jar, UTF-8 => less clear record-jar, I didn't look at the proposed charset feature for record-jar so far. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 08:15:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQjvy-0001u8-NC; Fri, 22 Sep 2006 08:15:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQjvx-0001u2-Ie for ltru@lists.ietf.org; Fri, 22 Sep 2006 08:15:09 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQjvw-0002Ku-8v for ltru@lists.ietf.org; Fri, 22 Sep 2006 08:15:09 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GQjvq-0006j0-6u for ltru@lists.ietf.org; Fri, 22 Sep 2006 14:15:02 +0200 Received: from pd9fbad55.dip0.t-ipconnect.de ([217.251.173.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Sep 2006 14:15:02 +0200 Received: from nobody by pd9fbad55.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Sep 2006 14:15:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 22 Sep 2006 14:08:39 +0200 Organization: Lines: 12 Message-ID: <4513D247.2A86@xyzzy.claranet.de> References: <013301c6dd89$cadbfa70$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad55.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: IANA XML registries X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > If they use subversion, wouldn't that be subversive? > Sorry, I'll leave now. I left yesterday for tasks like adding port 3960 svn to etc/services. That's another "registry" where using XML would be overkill. Subversion uses CRAM-MD5, I'm delighted (less so about their svn+x URI schemes) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 08:16:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQjxP-0003Kb-Gg; Fri, 22 Sep 2006 08:16:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQjxO-0003KU-0D for ltru@ietf.org; Fri, 22 Sep 2006 08:16:38 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQjxM-0002ef-PC for ltru@ietf.org; Fri, 22 Sep 2006 08:16:37 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060922121635.RLJU17675.mta9.adelphia.net@DGBP7M81>; Fri, 22 Sep 2006 08:16:36 -0400 Message-ID: <007901c6de40$f3154b10$6401a8c0@DGBP7M81> From: "Doug Ewell" To: References: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> <2227.61.112.211.238.1158907925.squirrel@webmail.w3.mag.keio.ac.jp> Subject: Re: [Ltru] Re: To XML or not to XML Date: Fri, 22 Sep 2006 05:16:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Felix Sasaki wrote: > Addison proposed "-1 to XML", while also stating that he would be fine > with a *non-normative* XML representation. My impression is that your > "0" is not incompatible to Addisons view - am I right? Correct. > I agree with Addisons proposal and also hope that the group adopts > *one* non-normative XML format. Otherwise different people outside > this group might just go ahead and create multiple XML representations > for the same purpose. If it's "non-normative," we can't really do anything about that, right? -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 08:20:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQk0u-0004k3-Lz; Fri, 22 Sep 2006 08:20:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQk0u-0004jq-0B for ltru@ietf.org; Fri, 22 Sep 2006 08:20:16 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQk0s-00031h-PK for ltru@ietf.org; Fri, 22 Sep 2006 08:20:15 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060922122011.LDQ25133.mta11.adelphia.net@DGBP7M81>; Fri, 22 Sep 2006 08:20:11 -0400 Message-ID: <007b01c6de41$73b2dc60$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> <2227.61.112.211.238.1158907925.squirrel@webmail.w3.mag.keio.ac.jp> <20060922072639.GD28368@nic.fr> Date: Fri, 22 Sep 2006 05:20:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Ltru] Re: To XML or not to XML X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > Opinions are welcome about: > ... > * names for the elements: follow the RFC or not? Definitely use the same names we use in the record-jar version. Choosing new names would be arbitrary and confusing. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 08:20:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQk15-0004vK-Ik; Fri, 22 Sep 2006 08:20:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQk14-0004vF-Sj for ltru@lists.ietf.org; Fri, 22 Sep 2006 08:20:26 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQk13-000357-Jq for ltru@lists.ietf.org; Fri, 22 Sep 2006 08:20:26 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GQk0j-0007y3-4V for ltru@lists.ietf.org; Fri, 22 Sep 2006 14:20:05 +0200 Received: from pd9fbad55.dip0.t-ipconnect.de ([217.251.173.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Sep 2006 14:20:05 +0200 Received: from nobody by pd9fbad55.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Sep 2006 14:20:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 22 Sep 2006 13:42:01 +0200 Organization: Lines: 26 Message-ID: <4513CC09.7AE7@xyzzy.claranet.de> References: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> <2227.61.112.211.238.1158907925.squirrel@webmail.w3.mag.keio.ac.jp> <20060922072639.GD28368@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad55.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Ltru] Re: To XML or not to XML X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > * Schema language to use (Frank used DTD, I used RelaxNG) The DTD is relevant for tools wanting this. Otherwise it is no problem to have both, or is it ? > * "elements or attributes", the old XML thread :-) Elements mostly, minus some additional xml:id / ref magic for checking XREFs. That results in , , , and replacing a few EMPTY by PCDATA. > * names for the elements: follow the RFC or not? As needed, the only interesting case is Preferred-Value as child of . We could get away with mixed content (?) That's from my POV a fun project, if it does everything we want (W3C validator + import into MS database + maybe use by IANA) it's fine. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 08:25:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQk5s-0006Qm-EG; Fri, 22 Sep 2006 08:25:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQk5r-0006Qh-3n for ltru@lists.ietf.org; Fri, 22 Sep 2006 08:25:23 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQk5p-0003cV-R0 for ltru@lists.ietf.org; Fri, 22 Sep 2006 08:25:23 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GQk5Y-0000mC-5t for ltru@lists.ietf.org; Fri, 22 Sep 2006 14:25:04 +0200 Received: from pd9fbad55.dip0.t-ipconnect.de ([217.251.173.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Sep 2006 14:25:04 +0200 Received: from nobody by pd9fbad55.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Sep 2006 14:25:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 22 Sep 2006 14:21:16 +0200 Organization: Lines: 18 Message-ID: <4513D53C.5B94@xyzzy.claranet.de> References: <006f01c6dd3d$9ed60ed0$6401a8c0@DGBP7M81> <63B577DE25954A46B14E5B1127C1FAE6.MAI@home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad55.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] Re: zh-hakka X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: > Frank wrote: >>> Actually, I believe they're planning on proposing RS for >>> Serbia... s/Frank/David/ > Unofficial Country Code Info: > RS/SRB for Serbia > ME/MNE for Montenegro > I would expect a newsletter to be published within the next > 4-5 weeks displaying the official results. I don't expect > there to be any changes but it isn't official Thanks for info, I got to update my rxwhois client for this. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 08:28:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQk8h-00087Q-KD; Fri, 22 Sep 2006 08:28:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQk8g-0007zw-4W for ltru@ietf.org; Fri, 22 Sep 2006 08:28:18 -0400 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQk8e-0003sj-OA for ltru@ietf.org; Fri, 22 Sep 2006 08:28:18 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 93FC64715; Fri, 22 Sep 2006 21:27:59 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01886-08; Fri, 22 Sep 2006 21:27:59 +0900 (JST) Received: from webmail.w3.mag.keio.ac.jp (toro [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 560CF44E1; Fri, 22 Sep 2006 21:27:59 +0900 (JST) Received: from 219.160.130.186 (SquirrelMail authenticated user fsasaki) by webmail.w3.mag.keio.ac.jp with HTTP; Fri, 22 Sep 2006 21:27:59 +0900 (JST) Message-ID: <2663.219.160.130.186.1158928079.squirrel@webmail.w3.mag.keio.ac.jp> In-Reply-To: <007901c6de40$f3154b10$6401a8c0@DGBP7M81> References: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> <2227.61.112.211.238.1158907925.squirrel@webmail.w3.mag.keio.ac.jp> <007901c6de40$f3154b10$6401a8c0@DGBP7M81> Date: Fri, 22 Sep 2006 21:27:59 +0900 (JST) Subject: Re: [Ltru] Re: To XML or not to XML From: "Felix Sasaki" To: "Doug Ewell" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-2022-jp X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fsasaki@w3.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > Felix Sasaki wrote: > >> Addison proposed "-1 to XML", while also stating that he would be fine >> with a *non-normative* XML representation. My impression is that your >> "0" is not incompatible to Addisons view - am I right? > > Correct. > >> I agree with Addisons proposal and also hope that the group adopts >> *one* non-normative XML format. Otherwise different people outside >> this group might just go ahead and create multiple XML representations >> for the same purpose. > > If it's "non-normative," we can't really do anything about that, right? IMO 1) "normative" means "this is the format you MUST / SHOULD understand if you implement this spec", whereas 2) "non-normative" means "for the ones who need it: this is just another format we recommend". As I said before, the purpose of 2) would be just to avoid confusion amon= g people who do the same thing, but without forcing everybody to go only that path. Anyway, since Martin wrote "The survey is "Switch to XML or stay with record-jar"' It seems that we don't have option 2). Felix > > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > RFC 4645 * UTN #14 > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 08:29:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQk9r-0000h6-17; Fri, 22 Sep 2006 08:29:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQk9q-0000h1-1L for ltru@lists.ietf.org; Fri, 22 Sep 2006 08:29:30 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQk9o-0003yy-P5 for ltru@lists.ietf.org; Fri, 22 Sep 2006 08:29:30 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 2B80826C126; Fri, 22 Sep 2006 14:29:18 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 22B3726C110; Fri, 22 Sep 2006 14:29:17 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 1478058EBBD; Fri, 22 Sep 2006 14:29:17 +0200 (CEST) Date: Fri, 22 Sep 2006 14:29:16 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20060922122916.GA18954@nic.fr> References: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> <2227.61.112.211.238.1158907925.squirrel@webmail.w3.mag.keio.ac.jp> <20060922072639.GD28368@nic.fr> <4513CC09.7AE7@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4513CC09.7AE7@xyzzy.claranet.de> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@lists.ietf.org Subject: [Ltru] Re: To XML or not to XML X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, Sep 22, 2006 at 01:42:01PM +0200, Frank Ellermann wrote a message of 26 lines which said: > > * Schema language to use (Frank used DTD, I used RelaxNG) > > The DTD is relevant for tools wanting this. Otherwise it > is no problem to have both, or is it ? DTD and RelaxNG do not have exactly the same expressive power. Which means it is impossible to have a DTD schema and a RelaxNG schema which accepts and rejects exactly the same documents. For a normative use, it is clearly a problem so we should have only one *normative* XML schema. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 08:53:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQkWb-0002kK-PK; Fri, 22 Sep 2006 08:53:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQkWa-0002kF-6f for ltru@ietf.org; Fri, 22 Sep 2006 08:53:00 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQkWY-0006sN-U3 for ltru@ietf.org; Fri, 22 Sep 2006 08:53:00 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060922125257.MXEM12100.mta13.adelphia.net@DGBP7M81> for ; Fri, 22 Sep 2006 08:52:57 -0400 Message-ID: <009901c6de46$07a33010$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Fri, 22 Sep 2006 05:52:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Ltru] Status of draft-4645bis-00 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I'll be out of town until Sunday, but hope to have a first draft of 4645bis posted to the list by Monday. Unless there's a decision to switch formats, the first draft will continue to specify the same format we are currently using. However, it will reference RFC 4646bis as the source of information on that format, and not the Eric Raymond document. As indicated, the order of existing Registry entries (including "amp" and "frr") won't be changed, but the 7,000 new language subtags will be inserted in alpha order within the 3-letter language subtags, and the extlangs will be added in their own section (as required), also in alpha order. Per Martin, the reference to 4645 will be informative and not normative. I expect the experts to fix any errors I make in that regard anyway. I'll also add the field "Comments: replaced by ISO code xxx" for all of the grandfathered sign-language tags, plus sgn-CH-de, again for consistency with the past. The lack of a Preferred-Value for the now-deprecated "zh-min", and the fact that no existing Description fields will be changed or deleted, will be explicitly mentioned. If anyone has any additional comments or concerns about 4645bis, please send them to the list. Again, I regret the fact that we aren't using the issue tracker so I can be sure of not missing anything. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 09:09:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQkmt-0001Oh-JN; Fri, 22 Sep 2006 09:09:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQkms-0001OJ-7K for ltru@lists.ietf.org; Fri, 22 Sep 2006 09:09:50 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQkmq-0000BD-UQ for ltru@lists.ietf.org; Fri, 22 Sep 2006 09:09:50 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GQkmK-0004Rj-EA for ltru@lists.ietf.org; Fri, 22 Sep 2006 15:09:18 +0200 Received: from pd9fbad55.dip0.t-ipconnect.de ([217.251.173.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Sep 2006 15:09:16 +0200 Received: from nobody by pd9fbad55.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Sep 2006 15:09:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 22 Sep 2006 15:08:23 +0200 Organization: Lines: 13 Message-ID: <4513E047.3C97@xyzzy.claranet.de> References: <009901c6de46$07a33010$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad55.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] Re: Status of draft-4645bis-00 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Per Martin, the reference to 4645 will be informative and not > normative. The question of "normative references" in an informational RFC is kind of bogus, we can continue to discuss this for 01. If you post the draft to the list please add the size (6xy KB) in the subject. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 09:14:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQkr1-0003fI-TV; Fri, 22 Sep 2006 09:14:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQkr0-0003fD-Mc for ltru@ietf.org; Fri, 22 Sep 2006 09:14:06 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQkqv-0000ea-Fq for ltru@ietf.org; Fri, 22 Sep 2006 09:14:06 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GQkqv-00019e-64; Fri, 22 Sep 2006 09:14:01 -0400 Date: Fri, 22 Sep 2006 09:14:01 -0400 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: To XML or not to XML Message-ID: <20060922131401.GA1813@ccil.org> References: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> <2227.61.112.211.238.1158907925.squirrel@webmail.w3.mag.keio.ac.jp> <20060922072639.GD28368@nic.fr> <4513CC09.7AE7@xyzzy.claranet.de> <20060922122916.GA18954@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060922122916.GA18954@nic.fr> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer scripsit: > DTD and RelaxNG do not have exactly the same expressive power. Which > means it is impossible to have a DTD schema and a RelaxNG schema which > accepts and rejects exactly the same documents. Almost. Within the domain of validation, a DTD may be losslessly converted to a RELAX NG schema. DTDs provide other things besides validation (attribute typing and defaulting, entity definition) that are not provided by RELAX NG. (Just trying to remove confusion.) -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Does anybody want any flotsam? / I've gotsam. Does anybody want any jetsam? / I can getsam. --Ogden Nash, No Doctors Today, Thank You _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 09:37:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlDe-0005CE-Bh; Fri, 22 Sep 2006 09:37:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlDd-0005Ar-9e for ltru@lists.ietf.org; Fri, 22 Sep 2006 09:37:29 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQlCV-0004Yu-Mz for ltru@lists.ietf.org; Fri, 22 Sep 2006 09:36:20 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M7HIGKI4CG00S3WB@mauve.mrochek.com> for ltru@lists.ietf.org; Fri, 22 Sep 2006 06:36:15 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M7HI3UR45C0008CX@mauve.mrochek.com>; Fri, 22 Sep 2006 06:36:14 -0700 (PDT) To: Martin Duerst Message-id: <01M7HIGJMYMK0008CX@mauve.mrochek.com> Date: Fri, 22 Sep 2006 06:31:55 -0700 (PDT) From: Ned Freed Subject: Re: [Ltru] To XML or not to XML In-reply-to: "Your message dated Fri, 22 Sep 2006 12:17:10 +0900" <6.0.0.20.2.20060922121257.07810740@localhost> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <4510E420.6010@xyzzy.claranet.de> <6.0.0.20.2.20060921183415.0368dd00@localhost> <1D0B84FC-6772-4CCE-89B9-C5968AE0B5FD@icann.org> <6.0.0.20.2.20060922121257.07810740@localhost> X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > Dear LTRU WG, > We have earlier discussed whether we should move to XML or not > for the registry. One unknown in these discussions was what > was (or wasn't) going on at IANA. > Thanks to David's help, we now have a much better idea of > what IANA is up to. Given that information, I'd like us to > make a firm decision on whether to use XML or not for RFC464xbis > soon. Please (re)state your preference. +1 in favor of shifting to XML. I don't think consumption of the current format is sufficiently widespread that changing now is going to be a problem. And as others have pointed out, an immense array of tools are available for processing XML, which may speed up adoption and possibly get us past a few of the boneheaded implementation blunders that invariably seem to creep in to implementations of newly standardized stuff. Ned _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 09:40:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlG6-00077p-VE; Fri, 22 Sep 2006 09:40:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlG5-00077V-HK for ltru@ietf.org; Fri, 22 Sep 2006 09:40:01 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQlG3-0005l1-OX for ltru@ietf.org; Fri, 22 Sep 2006 09:40:00 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060922133958.WAJN17675.mta9.adelphia.net@DGBP7M81>; Fri, 22 Sep 2006 09:39:58 -0400 Message-ID: <00aa01c6de4c$98eac000$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> <2227.61.112.211.238.1158907925.squirrel@webmail.w3.mag.keio.ac.jp> <007901c6de40$f3154b10$6401a8c0@DGBP7M81> <2663.219.160.130.186.1158928079.squirrel@webmail.w3.mag.keio.ac.jp> Subject: Re: [Ltru] Re: To XML or not to XML Date: Fri, 22 Sep 2006 06:39:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Felix Sasaki wrote: > IMO > 1) "normative" means "this is the format you MUST / SHOULD understand > if you implement this spec", whereas > 2) "non-normative" means "for the ones who need it: this is just > another format we recommend". > As I said before, the purpose of 2) would be just to avoid confusion > among people who do the same thing, but without forcing everybody to > go only that path. If you think people would use our non-normative XML version instead of rolling their own, then I believe you. > Anyway, since Martin wrote > "The survey is "Switch to XML or stay with record-jar"' > It seems that we don't have option 2). I think Martin wants to make sure we address the "switch or don't switch" question first, without confusing that issue with other issues. I agree with Martin that it would be a mistake to throw the field open to "pick your favorite format," since we already picked a format in LTRU 1.0. Changing an existing format is much more expensive than creating one from scratch. The only significant reason for changing it now is IANA's adoption of XML for internal use, a factor that does not exist for other formats. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 09:48:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlOb-0002Ig-DH; Fri, 22 Sep 2006 09:48:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlOa-0002Ia-5c for ltru@ietf.org; Fri, 22 Sep 2006 09:48:48 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQlOY-0007Uo-Us for ltru@ietf.org; Fri, 22 Sep 2006 09:48:48 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060922134846.WQCG17675.mta9.adelphia.net@DGBP7M81>; Fri, 22 Sep 2006 09:48:46 -0400 Message-ID: <00ae01c6de4d$d341c9f0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 22 Sep 2006 06:48:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Frank Ellermann Subject: [Ltru] Re: Status of draft-4645bis-00 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > If you post the draft to the list please add the size (6xy KB) > in the subject. Good point, I forgot to mention that. What I was planning to do was post the draft to the list, MINUS the Registry contents, and provide a temporary URL to the contents. No way do I want to spam the mailing list with 640K of data. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 09:56:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlWP-0004y3-LS; Fri, 22 Sep 2006 09:56:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlWN-0004xr-Ne for ltru@ietf.org; Fri, 22 Sep 2006 09:56:51 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQlWK-0000J9-Gi for ltru@ietf.org; Fri, 22 Sep 2006 09:56:51 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060922135647.FSYR25133.mta11.adelphia.net@DGBP7M81>; Fri, 22 Sep 2006 09:56:47 -0400 Message-ID: <00b201c6de4e$f23c20c0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Subject: Re: [Ltru] Re: To XML or not to XML Date: Fri, 22 Sep 2006 06:56:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I wrote: > Changing an existing format is much more expensive than creating one > from scratch. Better phrased as: Changing the format of an existing database is much more expensive than choosing a format at the time the database is created. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 . _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 11:08:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQmdg-0006Ys-JL; Fri, 22 Sep 2006 11:08:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQmdf-0006Yl-UC for ltru@ietf.org; Fri, 22 Sep 2006 11:08:27 -0400 Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQmdd-0007tr-IA for ltru@ietf.org; Fri, 22 Sep 2006 11:08:27 -0400 Received: from eupig2 (unverified [129.1.30.40]) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id ; Fri, 22 Sep 2006 15:08:16 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31217) with ESMTP id <0J60000G321SCB@eupig2.dtc.lon.ime.reuters.com>; Fri, 22 Sep 2006 15:08:16 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Fri, 22 Sep 2006 16:08:16 +0100 Date: Fri, 22 Sep 2006 16:07:23 +0100 From: Misha Wolf To: Stephen Deach , Richard Ishida Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: Updated article: Two-letter or three-letter language codes Thread-Index: AcbeWIAKoRTqvOcHSUGtlKLdyElFtwAABgsA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 22 Sep 2006 15:08:16.0147 (UTC) FILETIME=[EE335E30:01C6DE58] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ltru@ietf.org, www-international@w3.org Subject: [Ltru] RE: Updated article: Two-letter or three-letter language codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org That would be seriously broken. It would encourage=20 people to violate BCP 47. Misha -----Original Message----- From: Stephen Deach [mailto:sdeach@adobe.com]=20 Sent: 22 September 2006 16:05 To: Misha Wolf; Richard Ishida Cc: www-international@w3.org Subject: RE: Updated article: Two-letter or three-letter language codes I would strongly recomment taht all processing applications support both 2=20 & 3 letter ISO codes. It was the only way to get some countries and some applications (especially in business databases) simply always use the 3=20 letter coded. This email was sent to you by Reuters, the global news and information comp= any.=20 To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 12:18:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQnjj-0003N3-1H; Fri, 22 Sep 2006 12:18:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQnjh-0003My-Jo for ltru@ietf.org; Fri, 22 Sep 2006 12:18:45 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQnjf-00017i-6W for ltru@ietf.org; Fri, 22 Sep 2006 12:18:45 -0400 Received: from [10.72.66.13] (snvvpn-10-72-66-c13.corp.yahoo.com [10.72.66.13]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8MGIU5H067487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Sep 2006 09:18:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=uvV3ZCjf4PFylMftvaatQqoLRX0+pRgq+0CKC9RgQAo1jy6+Icr229g71HqO7GQl Message-ID: <45140CD6.7020109@yahoo-inc.com> Date: Fri, 22 Sep 2006 09:18:30 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: To XML or not to XML References: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> <2227.61.112.211.238.1158907925.squirrel@webmail.w3.mag.keio.ac.jp> <007901c6de40$f3154b10$6401a8c0@DGBP7M81> <2663.219.160.130.186.1158928079.squirrel@webmail.w3.mag.keio.ac.jp> <00aa01c6de4c$98eac000$6401a8c0@DGBP7M81> In-Reply-To: <00aa01c6de4c$98eac000$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Felix Sasaki wrote: > >> IMO >> 1) "normative" means "this is the format you MUST / SHOULD understand >> if you implement this spec", whereas >> 2) "non-normative" means "for the ones who need it: this is just >> another format we recommend". >> As I said before, the purpose of 2) would be just to avoid confusion >> among people who do the same thing, but without forcing everybody to >> go only that path. In particular, I think we would need to do the following: 1. Include a new subsection describing an alternate XML version of the registry, maintained by IANA in sync with the main record-jar version. 2. Include in that subsection a reference to a DTD published as an appendix in draft-4646bis, along with a mapping from the record-jar format to the DTD. Applications would then be free to choose whichever copy of the registry they wished, but the registration form and process would remain unchanged, and, if any conflict were to arise, the record-jar version of the registry would be authoritative. > > If you think people would use our non-normative XML version instead of > rolling their own, then I believe you. > >> Anyway, since Martin wrote >> "The survey is "Switch to XML or stay with record-jar"' >> It seems that we don't have option 2). > > I think Martin wants to make sure we address the "switch or don't > switch" question first, without confusing that issue with other issues. > > I agree with Martin that it would be a mistake to throw the field open > to "pick your favorite format," since we already picked a format in LTRU > 1.0. Changing an existing format is much more expensive than creating > one from scratch. The only significant reason for changing it now is > IANA's adoption of XML for internal use, a factor that does not exist > for other formats. > And IANA would be free to use XML internally... it is just that they'll be getting record-jar formatted data from the reviewer and they'll need to maintain the record-jar file. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 13:35:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQova-0003Xy-3D; Fri, 22 Sep 2006 13:35:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQovY-0003Xs-G8 for ltru@ietf.org; Fri, 22 Sep 2006 13:35:04 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQovU-00050V-2A for ltru@ietf.org; Fri, 22 Sep 2006 13:35:04 -0400 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 77992142282; Fri, 22 Sep 2006 10:34:57 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29065-01; Fri, 22 Sep 2006 10:34:53 -0700 (PDT) Received: from [10.1.1.207] (ip10.commerce.net [157.22.41.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C133214227C; Fri, 22 Sep 2006 10:34:53 -0700 (PDT) In-Reply-To: <6.0.0.20.2.20060921180422.09d3b6c0@localhost> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> <6.0.0.20.2.20060921180422.09d3b6c0@localhost> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8EF4241F-74F1-4B6A-97BD-B273DE6EA610@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ltru] IANA XML registries Date: Fri, 22 Sep 2006 10:34:51 -0700 To: Martin Duerst X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Yes, there's many ways to skin this cat, getting a registry (or any resource) from an HTTP server only if it has been updated. 1. HEAD or GET (or any other method) can be used with "If-Modified- Since" or "If-None-Match", depending on whether the client has a previous Last-Modified date or an ETag. The client might as well do the conditional GET as it's one request/response in either changed or unchanged case, and the server is instructed to do the right thing in returning or not returning the resource. Using an ETag is preferred to using a timestamp in theory. 2. HEAD can be used without a conditional header to find out the value of "Last-Modified" or the ETag. This is not as reliable as using a conditional, because the client might see that a resource was last modified since the most recent download according to its understanding of the times involved. But because the client knows the time of the most recent download and the server knows the last- modified time, there's a possibility for clock skew, timezone errors etc. 3. *IF* the server supports RFC3229, "Delta Encoding in HTTP", the client can make a single request for a compressed diff from the server if something has changed: GET /registry.xml HTTP/1.1 Host: example.org If-None-Match: "[value-of-last-etag]" A-IM: gdiff, gzip This is about the most efficient standardized thing to do for keeping a single large resource from an HTTP server up-to-date. I'm not sure how widespread support for RFC3229 is. Still, if the server doesn't support RFC3229, the request will behave just like a proper request designed for case 1 above. I don't think WebDAV adds anything for this case; WebDAV might be useful to keep a number of resources stored in the same collection on a single server, up-to-date on the client (by doing PROPFIND, asking for ETag values, and noting which ones had changed and required new downloads) Hope this wasn't more info than y'all wanted :) Lisa On Sep 21, 2006, at 2:05 AM, Martin Duerst wrote: > At 01:46 06/09/21, John Cowan wrote: > >> (My opinion FWIW is that a separate short file containing just the >> file-date record, without full diffs, is the best and simplest >> proposal.) > > My personal opinion is that the HTTP mechanisms are best, > because already widely implemented. In addition to the two > mechanisms mentioned (HEAD, If-Modified-Since), there are also > Etags (hash values that can be used to check for changes) and > I seem to remember that there is also some diff mechanism > (I guess from WebDAV, Lisa?). > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 13:54:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQpEe-0003MY-AL; Fri, 22 Sep 2006 13:54:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQpEd-0003MQ-5O for ltru@ietf.org; Fri, 22 Sep 2006 13:54:47 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQpEa-0006yY-T1 for ltru@ietf.org; Fri, 22 Sep 2006 13:54:47 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GQpEY-0004Cn-82; Fri, 22 Sep 2006 13:54:42 -0400 Date: Fri, 22 Sep 2006 13:54:42 -0400 To: Lisa Dusseault Subject: Re: [Ltru] IANA XML registries Message-ID: <20060922175442.GA14913@ccil.org> References: <4AA29C10-63B3-465D-9A6E-D7C02C72C07C@icann.org> <7.0.1.0.2.20060920140342.036d4e48@afrac.org> <0E361BCA-5B26-4937-B760-68CD002C2EA6@icann.org> <20060920164622.GF15905@ccil.org> <6.0.0.20.2.20060921180422.09d3b6c0@localhost> <8EF4241F-74F1-4B6A-97BD-B273DE6EA610@osafoundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8EF4241F-74F1-4B6A-97BD-B273DE6EA610@osafoundation.org> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Lisa Dusseault scripsit: > 1. HEAD or GET (or any other method) can be used with "If-Modified- > Since" or "If-None-Match", depending on whether the client has a > previous Last-Modified date or an ETag. The client might as well do > the conditional GET as it's one request/response in either changed or > unchanged case, and the server is instructed to do the right thing in > returning or not returning the resource. Using an ETag is preferred > to using a timestamp in theory. In this case, timestamp is probably easier, because the registry contains a last-modified timestamp in its content. So if you have a copy of the registry by whatever means, you can use that to construct a proper If-Modified-Since header. > 2. HEAD can be used without a conditional header to find out the > value of "Last-Modified" or the ETag. This is not as reliable as > using a conditional, because the client might see that a resource was > last modified since the most recent download according to its > understanding of the times involved. But because the client knows > the time of the most recent download and the server knows the last- > modified time, there's a possibility for clock skew, timezone errors > etc. Changes to the registry are separated by weeks to months, so clock differences should not be a problem. > [3.] This is about the most efficient standardized thing to do for keeping > a single large resource from an HTTP server up-to-date. I'm not sure > how widespread support for RFC3229 is. Still, if the server doesn't > support RFC3229, the request will behave just like a proper request > designed for case 1 above. The trick here is to arrange for the client to support it. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Original line from The Warrior's Apprentice by Lois McMaster Bujold: "Only on Barrayar would pulling a loaded needler start a stampede toward one." English-to-Russian-to-English mangling thereof: "Only on Barrayar you risk to lose support instead of finding it when you threat with the charged weapon." _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 17:58:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQt1y-00034r-Dw; Fri, 22 Sep 2006 17:57:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQt1w-00034j-T9 for ltru@lists.ietf.org; Fri, 22 Sep 2006 17:57:56 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQt1v-00057p-Ig for ltru@lists.ietf.org; Fri, 22 Sep 2006 17:57:56 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 9DAFE1E15B9; Fri, 22 Sep 2006 14:57:52 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Fri, 22 Sep 2006 14:57:52 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EF07@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Ned Freed' , Martin Duerst Subject: RE: [Ltru] To XML or not to XML Date: Fri, 22 Sep 2006 14:57:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, +1 to XML as the *normative* registry format. All - please answer Martin's question or start a new thread - half your answers seem to have wandered off into the unrelated swamp of XML as *informative*, which is neither interesting nor useful. If we do shift to XML as *normative*, then I'd urge that we also ask IANA to continue to make available the current record-jar format by machine-generation from the XML format registry. Cheers, - Ira PS - If we Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Ned Freed [mailto:ned.freed@mrochek.com] > Sent: Friday, September 22, 2006 9:32 AM > To: Martin Duerst > Cc: ltru@lists.ietf.org > Subject: Re: [Ltru] To XML or not to XML > > > > Dear LTRU WG, > > > We have earlier discussed whether we should move to XML or not > > for the registry. One unknown in these discussions was what > > was (or wasn't) going on at IANA. > > > Thanks to David's help, we now have a much better idea of > > what IANA is up to. Given that information, I'd like us to > > make a firm decision on whether to use XML or not for RFC464xbis > > soon. Please (re)state your preference. > > +1 in favor of shifting to XML. I don't think consumption of > the current format > is sufficiently widespread that changing now is going to be a > problem. And as > others have pointed out, an immense array of tools are > available for processing > XML, which may speed up adoption and possibly get us past a few of the > boneheaded implementation blunders that invariably seem to creep in to > implementations of newly standardized stuff. > > Ned > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.8/455 - Release Date: 9/22/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 18:21:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQtOd-0005ks-0m; Fri, 22 Sep 2006 18:21:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQtOc-0005kn-1Q for ltru@lists.ietf.org; Fri, 22 Sep 2006 18:21:22 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQtOa-00016o-L2 for ltru@lists.ietf.org; Fri, 22 Sep 2006 18:21:22 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8MMLCpE082170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Sep 2006 15:21:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=yKYXuIsOccXFSSvf8sO4XgIJ1F2vCtqwMReXXryAPr0GMggOpYqsYGHzA4uo74sR Message-ID: <451461D8.3000705@yahoo-inc.com> Date: Fri, 22 Sep 2006 15:21:12 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "McDonald, Ira" Subject: Re: [Ltru] To XML or not to XML References: <789E617C880666438EDEE30C2A3E8D10EF07@mailsrvnt05.enet.sharplabs.com> In-Reply-To: <789E617C880666438EDEE30C2A3E8D10EF07@mailsrvnt05.enet.sharplabs.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: 'Ned Freed' , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Ira, > > +1 to XML as the *normative* registry format. > > All - please answer Martin's question or start a new > thread - half your answers seem to have wandered off > into the unrelated swamp of XML as *informative*, > which is neither interesting nor useful. Whenever one has two or more versions of the same thing, it is usually a good idea to make one the "normative" version and the others derivative. That does not cast aspersions on someone's decision to use the derivative copy, especially if the two are carefully synchronized. In this case, we have registration forms, a registry format, and a process for creating and maintaining the list of valid subtags using the record-jar format. Changing to XML would require that each of these items be examined and aligned with the new format. We will also have to define the document structure, and create steps for validating the registry, and so forth. I have nothing against XML as a format for the registry. In fact, I think it was, originally, my idea. But I'm not in favor of doing a massive revision to RFC 4646 within weeks of its publication just so was can have a different file format. My suggestion (a third option) would avoid many of the problems above by keeping record-jar as the "official" format, but requiring IANA to maintain an XML copy in a particular format and synchronized with the "normative" source. If done properly, it will be indistinguishable from being a "normative reference" in its own right. I note that ISO 639 keeps tables on their web sites and many of us refer to those when looking up items (at least, until the advent of the LSTR!!), even those those references are far from "normative". In "wandering off into the unrelated swamp", I am attempting to have my cake and eat it too: I would like to see an XML *copy* of the registry, but I think it ill-timed and not an immediate requirement that we do it in 4646bis. I think this is a useful compromise. As described above, would this pose a problem for you? And if so, why? > > If we do shift to XML as *normative*, then I'd urge > that we also ask IANA to continue to make available > the current record-jar format by machine-generation > from the XML format registry. > Isn't this precisely the converse of my proposal? The record-jar would be "informative" and the XML "normative" in this case... Best Regards, Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 18:48:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQtoz-0001se-Ty; Fri, 22 Sep 2006 18:48:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQtoy-0001pT-Ht for ltru@lists.ietf.org; Fri, 22 Sep 2006 18:48:36 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQtox-0005Z8-5C for ltru@lists.ietf.org; Fri, 22 Sep 2006 18:48:36 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GQtoo-0006DG-7H for ltru@lists.ietf.org; Sat, 23 Sep 2006 00:48:26 +0200 Received: from du-017-229.access.de.clara.net ([212.82.246.229]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Sep 2006 00:48:26 +0200 Received: from nobody by du-017-229.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Sep 2006 00:48:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 23 Sep 2006 00:47:48 +0200 Organization: Lines: 22 Message-ID: <45146814.22A3@freenet.de> References: <789E617C880666438EDEE30C2A3E8D10EF07@mailsrvnt05.enet.sharplabs.com> <451461D8.3000705@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-017-229.access.de.clara.net X-Mailer: Mozilla 2.02 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] Re: To XML or not to XML X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nobody@xyzzy.claranet.de List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I'm not in favor of doing a massive revision to RFC 4646 > within weeks of its publication +1 (putting it very mildly) > I would like to see an XML *copy* of the registry is a new attempt, I've given up on "mixed content". The XML spec. is very hard to read with non-UTF-8 browsers. > I think it ill-timed and not an immediate requirement that > we do it in 4646bis. BTW, lstreg2.xml is now 140 KB based on 80 KB in lstreg9.txt, 75% more. For the 640 KB input I get over 1 MB, and that's a *TILT* as discussed in the 4646 round. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 19:37:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQuaM-00046b-Pz; Fri, 22 Sep 2006 19:37:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQuaL-0003z4-KG for ltru@ietf.org; Fri, 22 Sep 2006 19:37:33 -0400 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQuaK-0000Ia-0A for ltru@ietf.org; Fri, 22 Sep 2006 19:37:33 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id D2690462B; Sat, 23 Sep 2006 08:37:20 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07453-04; Sat, 23 Sep 2006 08:37:20 +0900 (JST) Received: from webmail.w3.mag.keio.ac.jp (toro [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 776FE4456; Sat, 23 Sep 2006 08:37:20 +0900 (JST) Received: from 221.188.42.209 (SquirrelMail authenticated user fsasaki) by webmail.w3.mag.keio.ac.jp with HTTP; Sat, 23 Sep 2006 08:37:20 +0900 (JST) Message-ID: <4217.221.188.42.209.1158968240.squirrel@webmail.w3.mag.keio.ac.jp> In-Reply-To: <45140CD6.7020109@yahoo-inc.com> References: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> <2227.61.112.211.238.1158907925.squirrel@webmail.w3.mag.keio.ac.jp> <007901c6de40$f3154b10$6401a8c0@DGBP7M81> <2663.219.160.130.186.1158928079.squirrel@webmail.w3.mag.keio.ac.jp> <00aa01c6de4c$98eac000$6401a8c0@DGBP7M81> <45140CD6.7020109@yahoo-inc.com> Date: Sat, 23 Sep 2006 08:37:20 +0900 (JST) Subject: Re: [Ltru] Re: To XML or not to XML From: "Felix Sasaki" To: "Addison Phillips" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-2022-jp X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fsasaki@w3.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 to Addisons proposal. Felix > > > Doug Ewell wrote: >> Felix Sasaki wrote: >> >>> IMO >>> 1) "normative" means "this is the format you MUST / SHOULD understand >>> if you implement this spec", whereas >>> 2) "non-normative" means "for the ones who need it: this is just >>> another format we recommend". >>> As I said before, the purpose of 2) would be just to avoid confusion >>> among people who do the same thing, but without forcing everybody to >>> go only that path. > > In particular, I think we would need to do the following: > > 1. Include a new subsection describing an alternate XML version of the > registry, maintained by IANA in sync with the main record-jar version. > > 2. Include in that subsection a reference to a DTD published as an > appendix in draft-4646bis, along with a mapping from the record-jar > format to the DTD. > > Applications would then be free to choose whichever copy of the registr= y > they wished, but the registration form and process would remain > unchanged, and, if any conflict were to arise, the record-jar version o= f > the registry would be authoritative. > >> >> If you think people would use our non-normative XML version instead of >> rolling their own, then I believe you. >> >>> Anyway, since Martin wrote >>> "The survey is "Switch to XML or stay with record-jar"' >>> It seems that we don't have option 2). >> >> I think Martin wants to make sure we address the "switch or don't >> switch" question first, without confusing that issue with other issues= . >> >> I agree with Martin that it would be a mistake to throw the field open >> to "pick your favorite format," since we already picked a format in LT= RU >> 1.0. Changing an existing format is much more expensive than creating >> one from scratch. The only significant reason for changing it now is >> IANA's adoption of XML for internal use, a factor that does not exist >> for other formats. >> > > And IANA would be free to use XML internally... it is just that they'll > be getting record-jar formatted data from the reviewer and they'll need > to maintain the record-jar file. > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 19:40:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQucm-0005wD-IV; Fri, 22 Sep 2006 19:40:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQucl-0005w8-AR for ltru@lists.ietf.org; Fri, 22 Sep 2006 19:40:03 -0400 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQucj-0000ix-VS for ltru@lists.ietf.org; Fri, 22 Sep 2006 19:40:03 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 9A0444661; Sat, 23 Sep 2006 08:40:02 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07483-03; Sat, 23 Sep 2006 08:40:02 +0900 (JST) Received: from webmail.w3.mag.keio.ac.jp (toro [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 62C854456; Sat, 23 Sep 2006 08:40:02 +0900 (JST) Received: from 221.188.42.209 (SquirrelMail authenticated user fsasaki) by webmail.w3.mag.keio.ac.jp with HTTP; Sat, 23 Sep 2006 08:40:02 +0900 (JST) Message-ID: <4221.221.188.42.209.1158968402.squirrel@webmail.w3.mag.keio.ac.jp> In-Reply-To: <451461D8.3000705@yahoo-inc.com> References: <789E617C880666438EDEE30C2A3E8D10EF07@mailsrvnt05.enet.sharplabs.com> <451461D8.3000705@yahoo-inc.com> Date: Sat, 23 Sep 2006 08:40:02 +0900 (JST) Subject: Re: [Ltru] To XML or not to XML From: "Felix Sasaki" To: "Addison Phillips" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-2022-jp X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fsasaki@w3.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > Hi Ira, [snip] > > In "wandering off into the unrelated swamp", I am attempting to have my > cake and eat it too: I would like to see an XML *copy* of the registry, > but I think it ill-timed and not an immediate requirement that we do it > in 4646bis. I think this is a useful compromise. +1 Felix _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 22 22:30:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQxHC-0005gB-JG; Fri, 22 Sep 2006 22:29:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQxHA-0005fJ-LC for ltru@lists.ietf.org; Fri, 22 Sep 2006 22:29:57 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQx5T-0002aB-8J for ltru@lists.ietf.org; Fri, 22 Sep 2006 22:17:56 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GQx5D-0003du-AT for ltru@lists.ietf.org; Sat, 23 Sep 2006 04:17:36 +0200 Received: from du-001-196.access.de.clara.net ([212.82.227.196]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Sep 2006 04:17:35 +0200 Received: from nobody by du-001-196.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Sep 2006 04:17:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 23 Sep 2006 03:53:11 +0200 Organization: Lines: 23 Message-ID: <45149387.4921@xyzzy.claranet.de> References: <00ae01c6de4d$d341c9f0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-196.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Ltru] 4646(bis) typo / issue (was: Status of draft-4645bis-00) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > What I was planning to do was post the draft to the list, > MINUS the Registry contents, and provide a temporary URL to > the contents. Okay. > No way do I want to spam the mailing list with 640K of data. The I-D will be a world record... :-) BTW, I propose that we fix en-boont and en-scouse silently to "redundant" instead of "grandfathered", the language subtag review list got that wrong. RFC 4646 3.3 3rd paragraph says "MAY have their type converted to 'redundant'; see item 12 in Section 3.6". This is a typo, it should be item 12 in section 3.4, and I think it's not optional if new variant + prefix intentionally match a grandfathered tag. Frank P.S. for Addison: please say "item 17 in Section 3.4" in 4646bis _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 23 00:14:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQyuK-0001dH-0n; Sat, 23 Sep 2006 00:14:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQyuI-0001YV-47 for ltru@lists.ietf.org; Sat, 23 Sep 2006 00:14:26 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQyuE-0001Bx-Oa for ltru@lists.ietf.org; Sat, 23 Sep 2006 00:14:26 -0400 Received: from [10.72.76.53] (snvvpn2-10-72-76-c53.corp.yahoo.com [10.72.76.53]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8N4E49X095367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Sep 2006 21:14:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=b04ahK2m+fg0pd1Z2+m1p9I0iab1iySYsJeswRB5Zzsx0xdKlqR59UbKCt2UuOqC Message-ID: <4514B48B.4030205@yahoo-inc.com> Date: Fri, 22 Sep 2006 21:14:03 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] 4646(bis) typo / issue References: <00ae01c6de4d$d341c9f0$6401a8c0@DGBP7M81> <45149387.4921@xyzzy.claranet.de> In-Reply-To: <45149387.4921@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > RFC 4646 3.3 3rd paragraph says "MAY have their type converted > to 'redundant'; see item 12 in Section 3.6". This is a typo, it > should be item 12 in section 3.4, and I think it's not optional > if new variant + prefix intentionally match a grandfathered tag. > You can fault our conversion of English to RFC 2119-ese here. The sentence really should have said something more like: "... might have had its type converted..." :-) I will correct this in draft-01. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 23 00:36:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQzFQ-0001a1-MJ; Sat, 23 Sep 2006 00:36:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQzFP-0001Zw-Jt for ltru@lists.ietf.org; Sat, 23 Sep 2006 00:36:15 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQzFO-0004Ek-As for ltru@lists.ietf.org; Sat, 23 Sep 2006 00:36:15 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GQzEt-0005Qw-I1 for ltru@lists.ietf.org; Sat, 23 Sep 2006 06:35:43 +0200 Received: from du-001-196.access.de.clara.net ([212.82.227.196]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Sep 2006 06:35:43 +0200 Received: from nobody by du-001-196.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Sep 2006 06:35:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 23 Sep 2006 06:33:42 +0200 Organization: Lines: 24 Message-ID: <4514B926.316B@xyzzy.claranet.de> References: <00ae01c6de4d$d341c9f0$6401a8c0@DGBP7M81> <45149387.4921@xyzzy.claranet.de> <4514B48B.4030205@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-196.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] Re: 4646(bis) typo / issue X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > You can fault our conversion of English to RFC 2119-ese here. > The sentence really should have said something more like: > "... might have had its type converted..." > :-) Yes, if the new variant is unrelated the tag better stays grandfathered. Or let's just reserve the few pseudo-variants: either they're registered matching the grandfathered tag, or they're off limits. Nobody needs gaulish if it's not related to cel-gaulish etc. > I will correct this in draft-01. Thanks. And submit that item number / section as an erratum. While they didn't have the time to publish a trivial erratum for 2045 submitted by the author after 20 months this doesn't imply that this state of the rfc-editor errata is acceptable. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 23 02:38:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR19K-0002Nu-Ms; Sat, 23 Sep 2006 02:38:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR19I-0002Nm-Mc for ltru@lists.ietf.org; Sat, 23 Sep 2006 02:38:04 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQx7c-00030Y-SI for ltru@lists.ietf.org; Fri, 22 Sep 2006 22:20:06 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GQx7a-0003yc-Fm for ltru@lists.ietf.org; Sat, 23 Sep 2006 04:20:02 +0200 Received: from du-001-196.access.de.clara.net ([212.82.227.196]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Sep 2006 04:20:02 +0200 Received: from nobody by du-001-196.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Sep 2006 04:20:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 23 Sep 2006 03:47:20 +0200 Organization: Lines: 21 Message-ID: <45149228.E55@xyzzy.claranet.de> References: <00a001c6ddb3$38cde560$6601a8c0@w3cishida> <6.0.0.20.2.20060922120613.07814c00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-196.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Ltru] Re: Updated article: Two-letter or three-letter language codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote on w3c.internationalization: > The rule "if there is a two-letter code and a three-letter > code, always use the two-letter code" is still very valid, > and will continue to be valid. The IANA registry is just an > additional way to find your language (sub)tag. Is that so for 4646bis ? I'm a bit lost with say oc, occ, and oc-prv (oc is on my "missing Suppress-Script" list). > This is basically not a change of language (sub)tags, but > just a change in how they are made available (one stop > shopping at IANA instead of having to check different lists). Plus the "stable forever" feature no matter what ISO does. Frank -- >> http://www.w3.org/International/questions/qa-lang-2or3 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 23 03:07:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR1bp-0004cg-Me; Sat, 23 Sep 2006 03:07:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR1bo-0004ca-DD for ltru@ietf.org; Sat, 23 Sep 2006 03:07:32 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GR1bn-00017w-6A for ltru@ietf.org; Sat, 23 Sep 2006 03:07:32 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GR1bk-00042R-OO; Sat, 23 Sep 2006 03:07:28 -0400 Date: Sat, 23 Sep 2006 03:07:28 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: Updated article: Two-letter or three-letter language codes Message-ID: <20060923070728.GC5795@ccil.org> References: <00a001c6ddb3$38cde560$6601a8c0@w3cishida> <6.0.0.20.2.20060922120613.07814c00@localhost> <45149228.E55@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45149228.E55@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > > The rule "if there is a two-letter code and a three-letter > > code, always use the two-letter code" is still very valid, > > and will continue to be valid. The IANA registry is just an > > additional way to find your language (sub)tag. > > Is that so for 4646bis ? Definitely. > I'm a bit lost with say oc, occ, and oc-prv (oc is on my "missing > Suppress-Script" list). 'oc' is the code element for Occitan, a macrolanguage encompassing five languages, namely Auvergnat, Gascon, Limousin, Languedocien, and Provencal. (The name "Provencal" is also sometimes applied to the macrolanguage as a whole, one of the confusions to which macrolanguages are often subject.) It is entirely valid as a language tag in cases when it is not necessary or desirable to be more exact. 'occ' is Occidental, an unrelated language. 'oci' is the 639-2 and 639-3 code element for Occitan, not used in IETF language tagging now or in future. "oc-prv" will be the 4646bis tag for the specific Provencal language, in cases where it is important to distinguish it from Occitan as a whole. > Plus the "stable forever" feature no matter what ISO does. Stable forever in the sense: once a valid subtag, always a valid subtag. Subtags may become deprecated and replaced by other subtags; specifically, region subtags may be deprecated as countries change their names and ISO 3166/MA changes tags as a result. -- Even the best of friends cannot John Cowan attend each others' funeral. cowan@ccil.org --Kehlog Albran, The Profit http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 23 03:21:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR1pb-00016j-SJ; Sat, 23 Sep 2006 03:21:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR1pa-00016N-L5 for ltru@ietf.org; Sat, 23 Sep 2006 03:21:46 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GR1pZ-0003b5-17 for ltru@ietf.org; Sat, 23 Sep 2006 03:21:46 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8N7LhPb022626 for ; Sat, 23 Sep 2006 16:21:43 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 5bca_2a1e2960_4ad4_11db_83d6_0014221fa3c9; Sat, 23 Sep 2006 16:21:43 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35706) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 23 Sep 2006 16:21:44 +0900 Message-Id: <6.0.0.20.2.20060923130504.023f7c40@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 23 Sep 2006 13:15:21 +0900 To: fsasaki@w3.org, "Doug Ewell" From: Martin Duerst Subject: Re: [Ltru] Re: To XML or not to XML In-Reply-To: <2663.219.160.130.186.1158928079.squirrel@webmail.w3.mag.ke io.ac.jp> References: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> <2227.61.112.211.238.1158907925.squirrel@webmail.w3.mag.keio.ac.jp> <007901c6de40$f3154b10$6401a8c0@DGBP7M81> <2663.219.160.130.186.1158928079.squirrel@webmail.w3.mag.keio.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 21:27 06/09/22, Felix Sasaki wrote: >> Felix Sasaki wrote: >>> I agree with Addisons proposal and also hope that the group adopts >>> *one* non-normative XML format. Otherwise different people outside >>> this group might just go ahead and create multiple XML representations >>> for the same purpose. >> >> If it's "non-normative," we can't really do anything about that, right? > >IMO >1) "normative" means "this is the format you MUST / SHOULD understand if >you implement this spec", whereas >2) "non-normative" means "for the ones who need it: this is just another >format we recommend". >As I said before, the purpose of 2) would be just to avoid confusion among >people who do the same thing, but without forcing everybody to go only >that path. >Anyway, since Martin wrote >"The survey is "Switch to XML or stay with record-jar"' >It seems that we don't have option 2). As a co-chair, I'm interested in getting closure on some main issues as early as possible. The initial mail in this thread was an attempt to decide on the *main* format, with the two options of record-jar and XML. Depending on the outcome, this does not exclude defining XML as a secondary format, but we should wait with that decision. Of course, expressions of preference such as "I prefer XML, but could live with record-jar if we also define an alternative XML format" are okay at this stage. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 23 03:21:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR1pZ-00015y-PH; Sat, 23 Sep 2006 03:21:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR1pY-00015t-S2 for ltru@ietf.org; Sat, 23 Sep 2006 03:21:44 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GR1pW-0003au-0V for ltru@ietf.org; Sat, 23 Sep 2006 03:21:44 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8N7LeCe018272 for ; Sat, 23 Sep 2006 16:21:40 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 0e8b_2816217c_4ad4_11db_8eee_0014221f2a2d; Sat, 23 Sep 2006 16:21:39 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35706) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 23 Sep 2006 16:21:41 +0900 Message-Id: <6.0.0.20.2.20060923112831.023f4d80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 23 Sep 2006 11:29:48 +0900 To: Misha Wolf , Stephen Deach , Richard Ishida From: Martin Duerst In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ltru@ietf.org, www-international@w3.org Subject: [Ltru] RE: Updated article: Two-letter or three-letter language codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Exactly. Codes should be converted at the boundaries to systems that can't handle anything else that three-letter codes. It has to be done one way, so it can as well be done both ways. Regards, Martin. At 00:07 06/09/23, Misha Wolf wrote: > >That would be seriously broken. It would encourage >people to violate BCP 47. > >Misha > > >-----Original Message----- >From: Stephen Deach [mailto:sdeach@adobe.com] >Sent: 22 September 2006 16:05 >To: Misha Wolf; Richard Ishida >Cc: www-international@w3.org >Subject: RE: Updated article: Two-letter or three-letter language codes > >I would strongly recomment taht all processing applications support both >2 >& 3 letter ISO codes. It was the only way to get some countries and some > >applications (especially in business databases) simply always use the 3 >letter coded. > > >This email was sent to you by Reuters, the global news and information company. >To find out more about Reuters visit www.about.reuters.com > >Any views expressed in this message are those of the individual sender, >except where the sender specifically states them to be the views of Reuters Ltd. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 23 05:58:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR4HQ-00043B-4h; Sat, 23 Sep 2006 05:58:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR4HP-000414-EO for ltru@ietf.org; Sat, 23 Sep 2006 05:58:39 -0400 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GR4HO-0005w0-2c for ltru@ietf.org; Sat, 23 Sep 2006 05:58:39 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 71A0F4731; Sat, 23 Sep 2006 18:58:32 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11687-02; Sat, 23 Sep 2006 18:58:31 +0900 (JST) Received: from webmail.w3.mag.keio.ac.jp (toro [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 243EA45F6; Sat, 23 Sep 2006 18:58:27 +0900 (JST) Received: from 218.110.62.174 (SquirrelMail authenticated user fsasaki) by webmail.w3.mag.keio.ac.jp with HTTP; Sat, 23 Sep 2006 18:58:31 +0900 (JST) Message-ID: <4735.218.110.62.174.1159005511.squirrel@webmail.w3.mag.keio.ac.jp> In-Reply-To: <6.0.0.20.2.20060923130504.023f7c40@localhost> References: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> <2227.61.112.211.238.1158907925.squirrel@webmail.w3.mag.keio.ac.jp> <007901c6de40$f3154b10$6401a8c0@DGBP7M81> <2663.219.160.130.186.1158928079.squirrel@webmail.w3.mag.keio.ac.jp> <6.0.0.20.2.20060923130504.023f7c40@localhost> Date: Sat, 23 Sep 2006 18:58:31 +0900 (JST) Subject: Re: [Ltru] Re: To XML or not to XML From: "Felix Sasaki" To: "Martin Duerst" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-2022-jp X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fsasaki@w3.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [snip] > > As a co-chair, I'm interested in getting closure on some main issues > as early as possible. The initial mail in this thread was an attempt > to decide on the *main* format, with the two options of record-jar > and XML. Depending on the outcome, this does not exclude defining XML > as a secondary format, but we should wait with that decision. Of course= , > expressions of preference such as "I prefer XML, but could live with > record-jar if we also define an alternative XML format" are okay at > this stage. Thank you for the clarification, Martin. I would say: I prefer XML, but think that it is not feasible to have it as a main format without major modifications in the draft. So let's have record-jar in the draft. For the idea of XML as a secondary format: +1. Felix _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 23 12:32:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRAQ9-0008UV-Gb; Sat, 23 Sep 2006 12:32:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRAQ8-0008UQ-2M for ltru@ietf.org; Sat, 23 Sep 2006 12:32:04 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRAQ5-0001z8-Hz for ltru@ietf.org; Sat, 23 Sep 2006 12:32:04 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1330508nfc for ; Sat, 23 Sep 2006 09:31:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=kxQ3dII5mMTWcAxrG31kjXCy05+Txnvhy5ormW/Yq1wI65OrB6+G7gMfXDwmMqX8uODuFkS9/WAZK/ssw6+AFMtYwX+0Dovcy8h1u9HMlR2xbsWx3LEQQy82PYexedyGZVGwsFCQQnseKv2DQDvvnfLUfk0GPhAQo+x5polgdAs= Received: by 10.49.8.10 with SMTP id l10mr3554631nfi; Sat, 23 Sep 2006 09:31:58 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Sat, 23 Sep 2006 09:31:58 -0700 (PDT) Message-ID: <30b660a20609230931y3c7ed6bah38549885e72b1aa8@mail.gmail.com> Date: Sat, 23 Sep 2006 09:31:58 -0700 From: "Mark Davis" To: "Stephen Deach" In-Reply-To: <6.1.1.1.2.20060923074520.02246bb0@namailhost.corp.adobe.com> MIME-Version: 1.0 References: <6.0.0.20.2.20060923112831.023f4d80@localhost> <6.1.1.1.2.20060923074520.02246bb0@namailhost.corp.adobe.com> X-Google-Sender-Auth: 958266b806170d10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Misha Wolf , www-international@w3.org, ltru@ietf.org Subject: [Ltru] Re: Updated article: Two-letter or three-letter language codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0151408504==" Errors-To: ltru-bounces@ietf.org --===============0151408504== Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SSBjYW4gYXBwcmVjaWF0ZSB0aGUgZ29hbC4gSW4gdGhlIGNhc2Ugb2YgbGFuZ3VhZ2UgdGFncywg d2UndmUgZG9uZQpzb21lIGFuYWx5c2lzIGhlcmUgYXQgR29vZ2xlLCBhbmQgYXQgbGVhc3QgaW4g YSAobGFyZ2UpIHNhbXBsZSBvZiB3ZWIKcGFnZXMgYW5kIHhtbCBkb2N1bWVudHMsIHRoZSB0aHJl ZS1sZXR0ZXIgY29kZXMgZG9uJ3QgYWNjb3VudCBmb3IgbWFueQpvZiB0aGUgcHJvYmxlbSBjYXNl cy4KClRvdGFsLVZhbGlkCTk5LjYyJQpUb3RhbC1XZWxsRm9ybWVkCTk5LjcxJQoKSGVyZSBhcmUg c29tZSBleGFtcGxlcyBvZiB3aGF0IHdlIGRvIGZpbmQuCgpJbGwtZm9ybWVkOgoodGhlIHNlY29u ZCBvbmUgaGFzIGEgc3BhY2UgYXQgdGhlIGVuZC4gdGhpcyBhbHNvIGV4Y2x1ZGVzIHgtLi4uLgp3 aGVyZSB0aGUgLi4uIGlzIGEgc3VidGFnIGxvbmdlciB0aGFuIDggLS0gdGhhdCBoYXMgYSBwcmV0 dHkgaGlnaApmcmVxdWVuY3kpClJhbmsJRnJlcXVlbmN5CXRhZwoxMDIJMC4wMTU5OTklCWVuLXVz LgoxMjIJMC4wMTAwNjglCWVuLXVzCjIxOQkwLjAwMTY2OCUJZXMtZXMtdHMKMzAyCTAuMDAwNjM4 JQlxPTAuNQozMDQJMC4wMDA2MzQlCXVuZGVmaW5lZAozMzkJMC4wMDA0MjklCWVzcGHvv71vbAoz OTEJMC4wMDAzMjUlCUluZG9uZXNpYW4KNDU4CTAuMDAwMTg1JQl1dGYtOAo0NjQJMC4wMDAxNzgl CXB0LWJyCjQ2NwkwLjAwMDE3MyUJdO+/vXJr77+9ZQo0ODEJMC4wMDAxNTglCXBvcnR1Z3Vlcwo1 MDMJMC4wMDAxMzglCWRlCjUxOAkwLjAwMDEyNiUJZXMtRVMtVFMKNTI5CTAuMDAwMTIwJQlWaWV0 bmFtZXNlCjU0NwkwLjAwMDEwNyUJc3Itc3AtbGF0bgo1NDkJMC4wMDAxMDclCWUKNTU1CTAuMDAw MTAyJQlMYW5ndWFnZSBUMjAwMjkgMjAwNS0wNS0xOAouLi4KCldlbGwtRm9ybWVkIGJ1dCBJbnZh bGlkCjg4CTAuMDI0NjMyJQllbi1zZWN1cmlkCjEzMwkwLjAwNzc5NiUJRW5nbGlzaAoxMzYJMC4w MDczNTMlCXhsCjE2MAkwLjAwNDczOSUJQ2hpbmVzZQoxNzYJMC4wMDMyMzUlCXpzCjE4MgkwLjAw MzA2MiUJdXMKMTgzCTAuMDAzMDU0JQljaGluZXNlCjE4NAkwLjAwMjg5MSUJZXNlcwoxODgJMC4w MDI0OTclCWluCjE4OQkwLjAwMjQ2MSUJcGRmCjIxMAkwLjAwMTgyNyUJZW4tc3AKMjEzCTAuMDAx NzcxJQllcy1zcAoyNDgJMC4wMDExNTAlCXpoLWNocwoyNTQJMC4wMDEwODglCUZyZW5jaAoyNjIJ MC4wMDEwMTklCXBvCjI3NgkwLjAwMDg3MyUJc3ItU1AKMjc5CTAuMDAwODY1JQluby1ib2sKMjg0 CTAuMDAwODAzJQlBcmFiaWMKMjkzCTAuMDAwNzMzJQlzcl9TUAoyOTkJMC4wMDA2NjclCWVuLWVu CjMwMwkwLjAwMDYzNyUJdWEKMzE4CTAuMDAwNTcwJQlqcAouLi4KCk9uIDkvMjMvMDYsIFN0ZXBo ZW4gRGVhY2ggPHNkZWFjaEBhZG9iZS5jb20+IHdyb3RlOgo+Cj4gSSBqdXN0IHdhbnRlZCB0byBt YWtlIHN1cmUgdGhpcyAic2hvcnRlc3QgY29kZSIgaXNzdWUgd2FzIGNvbnNpZGVyZWQKPiBjYXJl ZnVsbHkuCj4gICAgQSBsb3Qgb2YgcGVvcGxlIEkndmUgdGFsa2VkIHRvIGFib3V0IGludGVybmF0 aW9uYWxpemF0aW9uIGlzc3VlcyBvdmVyCj4gdGhlIHllYXJzIHNpbXBseSBoYWQgImFzc3VtZWQi IHRoYXQgdGhlIDMtbGV0dGVyIElTTyBjb2RlcyBzdXBlcmNlZGVkIHRoZQo+IDItbGV0dGVyIG9u ZXMsIG9yIGNob3NlIHRvIHVzZSBhbGwgMy1sZXR0ZXIgY29kZXMgcmF0aGVyIHRoYW4gYSBtaXgg b2YgMiAmCj4gMyBiZWNhdXNlIGl0IHdhcyBlYXNpZXIgdG8gbWFrZSBpdCBhIGZpeGVkLWxlbmd0 aCBmaWVsZC4KPgo+IEkgdW5kZXJzdGFuZCB5b3VyIGdvYWwgaXMgdG8gZXZlbnR1YWxseSBtYWtl IHRoaXMgc2ltcGxlciwgYnkgZWxpbWluYXRpbmcKPiBtdWx0aXBsZSBmb3JtYXRzIGZvciBlYWNo IHN1YnRva2VuIGFuZCBtb3ZpbmcgdG8gYSBzaW5nbGUgcmVnaXN0cnkvbGlzdC4gQXMKPiBhIGdl bmVyYWwgcHJvY2VzcyBJIGFsd2F5cyB0cnkgdG8gYWNjZXB0IGlsbC1mb3JtZWQgaW5wdXQsIGJ1 dCBlbWl0Cj4gY29ycmVjdGVkIG91dHB1dCAoc2luY2UgeW91IHByZXR0eSBtdWNoIGhhdmUgdG8g Z3JhbmRmYXRoZXIgYWxsIHBhc3QgZm9ybWF0cykuCj4KPgo+IEF0IDIwMDYuMDkuMjMtMTE6Mjko KzA5MDApLCBNYXJ0aW4gRHVlcnN0IHdyb3RlOgo+ID5FeGFjdGx5LiBDb2RlcyBzaG91bGQgYmUg Y29udmVydGVkIGF0IHRoZSBib3VuZGFyaWVzIHRvIHN5c3RlbXMgdGhhdAo+ID5jYW4ndCBoYW5k bGUgYW55dGhpbmcgZWxzZSB0aGF0IHRocmVlLWxldHRlciBjb2Rlcy4gSXQgaGFzIHRvIGJlIGRv bmUKPiA+b25lIHdheSwgc28gaXQgY2FuIGFzIHdlbGwgYmUgZG9uZSBib3RoIHdheXMuCj4gPgo+ ID5SZWdhcmRzLCAgIE1hcnRpbi4KPiA+Cj4gPkF0IDAwOjA3IDA2LzA5LzIzLCBNaXNoYSBXb2xm IHdyb3RlOgo+ID4gPgo+ID4gPlRoYXQgd291bGQgYmUgc2VyaW91c2x5IGJyb2tlbi4gIEl0IHdv dWxkIGVuY291cmFnZQo+ID4gPnBlb3BsZSB0byB2aW9sYXRlIEJDUCA0Ny4KPiA+ID4KPiA+ID5N aXNoYQo+ID4gPgo+ID4gPgo+ID4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gPiA+RnJv bTogU3RlcGhlbiBEZWFjaCBbbWFpbHRvOnNkZWFjaEBhZG9iZS5jb21dCj4gPiA+U2VudDogMjIg U2VwdGVtYmVyIDIwMDYgMTY6MDUKPiA+ID5UbzogTWlzaGEgV29sZjsgUmljaGFyZCBJc2hpZGEK PiA+ID5DYzogd3d3LWludGVybmF0aW9uYWxAdzMub3JnCj4gPiA+U3ViamVjdDogUkU6IFVwZGF0 ZWQgYXJ0aWNsZTogVHdvLWxldHRlciBvciB0aHJlZS1sZXR0ZXIgbGFuZ3VhZ2UgY29kZXMKPiA+ ID4KPiA+ID5JIHdvdWxkIHN0cm9uZ2x5IHJlY29tbWVudCB0YWh0IGFsbCBwcm9jZXNzaW5nIGFw cGxpY2F0aW9ucyBzdXBwb3J0IGJvdGgKPiA+ID4yCj4gPiA+JiAzIGxldHRlciBJU08gY29kZXMu IEl0IHdhcyB0aGUgb25seSB3YXkgdG8gZ2V0IHNvbWUgY291bnRyaWVzIGFuZCBzb21lCj4gPiA+ Cj4gPiA+YXBwbGljYXRpb25zIChlc3BlY2lhbGx5IGluIGJ1c2luZXNzIGRhdGFiYXNlcykgc2lt cGx5IGFsd2F5cyB1c2UgdGhlIDMKPiA+ID5sZXR0ZXIgY29kZWQuCj4gPiA+Cj4gPiA+Cj4gPiA+ VGhpcyBlbWFpbCB3YXMgc2VudCB0byB5b3UgYnkgUmV1dGVycywgdGhlIGdsb2JhbCBuZXdzIGFu ZCBpbmZvcm1hdGlvbgo+ID4gY29tcGFueS4KPiA+ID5UbyBmaW5kIG91dCBtb3JlIGFib3V0IFJl dXRlcnMgdmlzaXQgd3d3LmFib3V0LnJldXRlcnMuY29tCj4gPiA+Cj4gPiA+QW55IHZpZXdzIGV4 cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRl ciwKPiA+ID5leGNlcHQgd2hlcmUgdGhlIHNlbmRlciBzcGVjaWZpY2FsbHkgc3RhdGVzIHRoZW0g dG8gYmUgdGhlIHZpZXdzIG9mCj4gPiBSZXV0ZXJzIEx0ZC4KPiA+Cj4gPgo+ID4jLSMtIyAgTWFy dGluIEouIER1InJzdCwgQXNzb2MuIFByb2Zlc3NvciwgQW95YW1hIEdha3VpbiBVbml2ZXJzaXR5 Cj4gPiMtIy0jICBodHRwOi8vd3d3LnN3Lml0LmFveWFtYS5hYy5qcCAgICAgICBtYWlsdG86ZHVl cnN0QGl0LmFveWFtYS5hYy5qcAo+Cj4KPiAtLS1TdGV2ZSBEZWFjaAo+ICAgICBzZGVhY2hAYWRv YmUuY29tCj4KPgo+Cg== --===============0151408504== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0151408504==-- From ltru-bounces@ietf.org Sat Sep 23 17:02:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GREdd-0004Yd-8i; Sat, 23 Sep 2006 17:02:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GREdc-0004YX-Cc for ltru@ietf.org; Sat, 23 Sep 2006 17:02:16 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GREda-00038O-3X for ltru@ietf.org; Sat, 23 Sep 2006 17:02:16 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 413D5240815; Sat, 23 Sep 2006 23:02:03 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 585CD115F6; Sat, 23 Sep 2006 22:58:47 +0200 (CEST) Date: Sat, 23 Sep 2006 22:58:47 +0200 From: Stephane Bortzmeyer To: Addison Phillips Message-ID: <20060923205847.GA3519@sources.org> References: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> <2227.61.112.211.238.1158907925.squirrel@webmail.w3.mag.keio.ac.jp> <007901c6de40$f3154b10$6401a8c0@DGBP7M81> <2663.219.160.130.186.1158928079.squirrel@webmail.w3.mag.keio.ac.jp> <00aa01c6de4c$98eac000$6401a8c0@DGBP7M81> <45140CD6.7020109@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45140CD6.7020109@yahoo-inc.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: LTRU Working Group Subject: [Ltru] Re: To XML or not to XML X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, Sep 22, 2006 at 09:18:30AM -0700, Addison Phillips wrote a message of 64 lines which said: > 2. Include in that subsection a reference to a DTD published as an > appendix in draft-4646bis, along with a mapping from the record-jar > format to the DTD. Please replace "a DTD" by "a schema". DTD is one of several possible schema languages for XML and most XML users believe it is the worst. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 23 21:13:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRIYi-0002L5-Jo; Sat, 23 Sep 2006 21:13:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR97D-00040q-PP for ltru@ietf.org; Sat, 23 Sep 2006 11:08:27 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GR8yY-0004lL-EF for ltru@ietf.org; Sat, 23 Sep 2006 10:59:34 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Sat, 23 Sep 2006 07:59:23 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k8NEuxnN002320; Sat, 23 Sep 2006 07:57:00 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k8NEwp7U009689; Sat, 23 Sep 2006 07:59:11 -0700 (PDT) Received: from SDEACH-T42P.adobe.com ([10.7.240.207]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 23 Sep 2006 07:58:45 -0700 Message-Id: <6.1.1.1.2.20060923074520.02246bb0@namailhost.corp.adobe.com> X-Sender: sdeach@namailhost.corp.adobe.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Sat, 23 Sep 2006 07:58:45 -0700 To: Martin Duerst , Misha Wolf , Stephen Deach , Richard Ishida From: Stephen Deach In-Reply-To: <6.0.0.20.2.20060923112831.023f4d80@localhost> References: <6.0.0.20.2.20060923112831.023f4d80@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 23 Sep 2006 14:58:46.0004 (UTC) FILETIME=[C4C83340:01C6DF20] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Sat, 23 Sep 2006 21:13:27 -0400 Cc: ltru@ietf.org, www-international@w3.org Subject: [Ltru] RE: Updated article: Two-letter or three-letter language codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I just wanted to make sure this "shortest code" issue was considered carefully. A lot of people I've talked to about internationalization issues over the years simply had "assumed" that the 3-letter ISO codes superceded the 2-letter ones, or chose to use all 3-letter codes rather than a mix of 2 & 3 because it was easier to make it a fixed-length field. I understand your goal is to eventually make this simpler, by eliminating multiple formats for each subtoken and moving to a single registry/list. As a general process I always try to accept ill-formed input, but emit corrected output (since you pretty much have to grandfather all past formats). At 2006.09.23-11:29(+0900), Martin Duerst wrote: >Exactly. Codes should be converted at the boundaries to systems that >can't handle anything else that three-letter codes. It has to be done >one way, so it can as well be done both ways. > >Regards, Martin. > >At 00:07 06/09/23, Misha Wolf wrote: > > > >That would be seriously broken. It would encourage > >people to violate BCP 47. > > > >Misha > > > > > >-----Original Message----- > >From: Stephen Deach [mailto:sdeach@adobe.com] > >Sent: 22 September 2006 16:05 > >To: Misha Wolf; Richard Ishida > >Cc: www-international@w3.org > >Subject: RE: Updated article: Two-letter or three-letter language codes > > > >I would strongly recomment taht all processing applications support both > >2 > >& 3 letter ISO codes. It was the only way to get some countries and some > > > >applications (especially in business databases) simply always use the 3 > >letter coded. > > > > > >This email was sent to you by Reuters, the global news and information > company. > >To find out more about Reuters visit www.about.reuters.com > > > >Any views expressed in this message are those of the individual sender, > >except where the sender specifically states them to be the views of > Reuters Ltd. > > >#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University >#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp ---Steve Deach sdeach@adobe.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 24 02:04:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRN5p-0001wg-MA; Sun, 24 Sep 2006 02:03:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRN5o-0001wX-Ib for ltru@ietf.org; Sun, 24 Sep 2006 02:03:56 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRN5l-0007Vd-Nt for ltru@ietf.org; Sun, 24 Sep 2006 02:03:56 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8O63ofo017281 for ; Sun, 24 Sep 2006 15:03:50 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 0de5_72bcfbe2_4b92_11db_8db6_0014221f2a2d; Sun, 24 Sep 2006 15:03:49 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:52403) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 24 Sep 2006 15:03:47 +0900 Message-Id: <6.0.0.20.2.20060924113309.02411740@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 24 Sep 2006 11:56:41 +0900 To: "Mark Davis" , "Stephen Deach" From: Martin Duerst In-Reply-To: <30b660a20609230931y3c7ed6bah38549885e72b1aa8@mail.gmail.co m> References: <6.0.0.20.2.20060923112831.023f4d80@localhost> <6.1.1.1.2.20060923074520.02246bb0@namailhost.corp.adobe.com> <30b660a20609230931y3c7ed6bah38549885e72b1aa8@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Misha Wolf , ltru@ietf.org, www-international@w3.org Subject: [Ltru] Re: Updated article: Two-letter or three-letter language codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Mark, Many thanks for this interesting data. In my mailer, the line endings didn't work very well, so I refomatted it (at the same time, my mailer messed up the non-ASCII stuff, sorry). The only three-letter code I can see is pdf, for which we can blame Steve's company :-). On the other hand, in the list, there are a few items (such as en-us, pt-br) that look perfectly fine. What was wrong with them? Regards, Martin. At 01:31 06/09/24, Mark Davis wrote: >I can appreciate the goal. In the case of language tags, we've done >some analysis here at Google, and at least in a (large) sample of web >pages and xml documents, the three-letter codes don't account for many >of the problem cases. > >Total-Valid 99.62% >Total-WellFormed 99.71% > >Here are some examples of what we do find. > >Ill-formed: >(the second one has a space at the end. this also excludes x-.... >where the ... is a subtag longer than 8 -- that has a pretty high >frequency) >Rank Frequency tag >102 0.015999% en-us. >122 0.010068% en-us >219 0.001668% es-es-ts >302 0.000638% q=0.5 >304 0.000634% undefined >339 0.000429% espa$B~A%9(Bol >391 0.000325% Indonesian >458 0.000185% utf-8 >464 0.000178% pt-br >467 0.000173% t$B~A%9(Brk$B~A%9(Be >481 0.000158% portugues >503 0.000138% de >518 From ltru-bounces@ietf.org Sun Sep 24 02:04:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRN5p-0001wg-MA; Sun, 24 Sep 2006 02:03:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRN5o-0001wX-Ib for ltru@ietf.org; Sun, 24 Sep 2006 02:03:56 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRN5l-0007Vd-Nt for ltru@ietf.org; Sun, 24 Sep 2006 02:03:56 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8O63ofo017281 for ; Sun, 24 Sep 2006 15:03:50 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 0de5_72bcfbe2_4b92_11db_8db6_0014221f2a2d; Sun, 24 Sep 2006 15:03:49 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:52403) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 24 Sep 2006 15:03:47 +0900 Message-Id: <6.0.0.20.2.20060924113309.02411740@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 24 Sep 2006 11:56:41 +0900 To: "Mark Davis" , "Stephen Deach" From: Martin Duerst In-Reply-To: <30b660a20609230931y3c7ed6bah38549885e72b1aa8@mail.gmail.co m> References: <6.0.0.20.2.20060923112831.023f4d80@localhost> <6.1.1.1.2.20060923074520.02246bb0@namailhost.corp.adobe.com> <30b660a20609230931y3c7ed6bah38549885e72b1aa8@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Misha Wolf , ltru@ietf.org, www-international@w3.org Subject: [Ltru] Re: Updated article: Two-letter or three-letter language codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Mark, Many thanks for this interesting data. In my mailer, the line endings didn't work very well, so I refomatted it (at the same time, my mailer messed up the non-ASCII stuff, sorry). The only three-letter code I can see is pdf, for which we can blame Steve's company :-). On the other hand, in the list, there are a few items (such as en-us, pt-br) that look perfectly fine. What was wrong with them? Regards, Martin. At 01:31 06/09/24, Mark Davis wrote: >I can appreciate the goal. In the case of language tags, we've done >some analysis here at Google, and at least in a (large) sample of web >pages and xml documents, the three-letter codes don't account for many >of the problem cases. > >Total-Valid 99.62% >Total-WellFormed 99.71% > >Here are some examples of what we do find. > >Ill-formed: >(the second one has a space at the end. this also excludes x-.... >where the ... is a subtag longer than 8 -- that has a pretty high >frequency) >Rank Frequency tag >102 0.015999% en-us. >122 0.010068% en-us >219 0.001668% es-es-ts >302 0.000638% q=0.5 >304 0.000634% undefined >339 0.000429% espa$B~A%9(Bol >391 0.000325% Indonesian >458 0.000185% utf-8 >464 0.000178% pt-br >467 0.000173% t$B~A%9(Brk$B~A%9(Be >481 0.000158% portugues >503 0.000138% de >518 0.000126% es-ES-TS >529 0.000120% Vietnamese >547 0.000107% sr-sp-latn >549 0.000107% e >555 0.000102% Language T20029 2005-05-18 >... > >Well-Formed but Invalid >88 0.024632% en-securid >133 0.007796% English >136 0.007353% xl >160 0.004739% Chinese >176 0.003235% zs >182 0.003062% us >183 0.003054% chinese >184 0.002891% eses >188 0.002497% in >189 0.002461% pdf >210 0.001827% en-sp >213 0.001771% es-sp >248 0.001150% zh-chs >254 0.001088% French >262 0.001019% po >276 0.000873% sr-SP >279 0.000865% no-bok >284 0.000803% Arabic >293 0.000733% sr_SP >299 0.000667% en-en >303 0.000637% ua >318 0.000570% jp #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 24 02:04:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRN5p-0001wc-J8; Sun, 24 Sep 2006 02:03:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRN5o-0001vq-94 for ltru@ietf.org; Sun, 24 Sep 2006 02:03:56 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRN5m-0007Vn-Jt for ltru@ietf.org; Sun, 24 Sep 2006 02:03:56 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8O63riO017298 for ; Sun, 24 Sep 2006 15:03:53 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 0e4b_74e0b51c_4b92_11db_8e9b_0014221f2a2d; Sun, 24 Sep 2006 15:03:53 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:52403) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 24 Sep 2006 15:03:51 +0900 Message-Id: <6.0.0.20.2.20060924120617.03eb5120@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 24 Sep 2006 12:23:15 +0900 To: Stephen Deach , Misha Wolf , Richard Ishida From: Martin Duerst In-Reply-To: <6.1.1.1.2.20060923074520.02246bb0@namailhost.corp.adobe.co m> References: <6.0.0.20.2.20060923112831.023f4d80@localhost> <6.1.1.1.2.20060923074520.02246bb0@namailhost.corp.adobe.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ltru@ietf.org, www-international@w3.org Subject: [Ltru] RE: Updated article: Two-letter or three-letter language codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 23:58 06/09/23, Stephen Deach wrote: >I just wanted to make sure this "shortest code" issue was considered carefully. > A lot of people I've talked to about internationalization issues over the years simply had "assumed" that the 3-letter ISO codes superceded the 2-letter ones, or chose to use all 3-letter codes rather than a mix of 2 & 3 because it0.000126% es-ES-TS >529 0.000120% Vietnamese >547 0.000107% sr-sp-latn >549 0.000107% e >555 0.000102% Language T20029 2005-05-18 >... > >Well-Formed but Invalid >88 0.024632% en-securid >133 0.007796% English >136 0.007353% xl >160 0.004739% Chinese >176 0.003235% zs >182 0.003062% us >183 0.003054% chinese >184 0.002891% eses >188 0.002497% in >189 0.002461% pdf >210 0.001827% en-sp >213 0.001771% es-sp >248 0.001150% zh-chs >254 0.001088% French >262 0.001019% po >276 0.000873% sr-SP >279 0.000865% no-bok >284 0.000803% Arabic >293 0.000733% sr_SP >299 0.000667% en-en >303 0.000637% ua >318 0.000570% jp #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 24 02:04:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRN5p-0001wc-J8; Sun, 24 Sep 2006 02:03:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRN5o-0001vq-94 for ltru@ietf.org; Sun, 24 Sep 2006 02:03:56 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRN5m-0007Vn-Jt for ltru@ietf.org; Sun, 24 Sep 2006 02:03:56 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8O63riO017298 for ; Sun, 24 Sep 2006 15:03:53 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 0e4b_74e0b51c_4b92_11db_8e9b_0014221f2a2d; Sun, 24 Sep 2006 15:03:53 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:52403) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 24 Sep 2006 15:03:51 +0900 Message-Id: <6.0.0.20.2.20060924120617.03eb5120@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 24 Sep 2006 12:23:15 +0900 To: Stephen Deach , Misha Wolf , Richard Ishida From: Martin Duerst In-Reply-To: <6.1.1.1.2.20060923074520.02246bb0@namailhost.corp.adobe.co m> References: <6.0.0.20.2.20060923112831.023f4d80@localhost> <6.1.1.1.2.20060923074520.02246bb0@namailhost.corp.adobe.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ltru@ietf.org, www-international@w3.org Subject: [Ltru] RE: Updated article: Two-letter or three-letter language codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 23:58 06/09/23, Stephen Deach wrote: >I just wanted to make sure this "shortest code" issue was considered carefully. > A lot of people I've talked to about internationalization issues over the years simply had "assumed" that the 3-letter ISO codes superceded the 2-letter ones, or chose to use all 3-letter codes rather than a mix of 2 & 3 because it was easier to make it a fixed-length field. IETF language tags always have been variable-length. >I understand your goal is to eventually make this simpler, by eliminating multiple formats for each subtoken and moving to a single registry/list. This is not a matter of future development. RFC 3066, which sorted out this issue, has been published in January 2001. Mark's data also seems to show that this is quite well respected. >As a general process I always try to accept ill-formed input, but emit corrected output (since you pretty much have to grandfather all past formats). In the case of language tags, this is a very good policy for interfaces between other systems and the Internet protocols and formats that use RFC 4646 language tags. Regards, Martin. >At 2006.09.23-11:29(+0900), Martin Duerst wrote: >>Exactly. Codes should be converted at the boundaries to systems that >>can't handle anything else that three-letter codes. It has to be done >>one way, so it can as well be done both ways. >> >>Regards, Martin. >> >>At 00:07 06/09/23, Misha Wolf wrote: >> > >> >That would be seriously broken. It would encourage >> >people to violate BCP 47. >> > >> >Misha >> > >> > >> >-----Original Message----- >> >From: Stephen Deach [mailto:sdeach@adobe.com] >> >Sent: 22 September 2006 16:05 >> >To: Misha Wolf; Richard Ishida >> >Cc: www-international@w3.org >> >Subject: RE: Updated article: Two-letter or three-letter language codes >> > >> >I would strongly recomment taht all processing applications support both >> >2 >> >& 3 letter ISO codes. It was the only way to get some countries and some >> > >> >applications (especially in business databases) simply always use the 3 >> >letter coded. >> > >> > >> >This email was sent to you by Reuters, the global news and information company. >> >To find out more about Reuters visit www.about.reuters.com >> > >> >Any views expressed in this message are those of the individual sender, >> >except where the sender specifically states them to be the views of Reuters Ltd. >> >> >>#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University >>#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > >---Steve Deach > sdeach@adobe.com #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru was easier to make it a fixed-length field. IETF language tags always have been variable-length. >I understand your goal is to eventually make this simpler, by eliminating multiple formats for each subtoken and moving to a single registry/list. This is not a matter of future development. RFC 3066, which sorted out this issue, has been published in January 2001. Mark's data also seems to show that this is quite well respected. >As a general process I always try to accept ill-formed input, but emit corrected output (since you pretty much have to grandfather all past formats). In the case of language tags, this is a very good policy for interfaces between other systems and the Internet protocols and formats that use RFC 4646 language tags. Regards, Martin. >At 2006.09.23-11:29(+0900), Martin Duerst wrote: >>Exactly. Codes should be converted at the boundaries to systems that >>can't handle anything else that three-letter codes. It has to be done >>one way, so it can as well be done both ways. >> >>Regards, Martin. >> >>At 00:07 06/09/23, Misha Wolf wrote: >> > >> >That would be seriously broken. It would encourage >> >people to violate BCP 47. >> > >> >Misha >> > >> > >> >-----Original Message----- >> >From: Stephen Deach [mailto:sdeach@adobe.com] >> >Sent: 22 September 2006 16:05 >> >To: Misha Wolf; Richard Ishida >> >Cc: www-international@w3.org >> >Subject: RE: Updated article: Two-letter or three-letter language codes >> > >> >I would strongly recomment taht all processing applications support both >> >2 >> >& 3 letter ISO codes. It was the only way to get some countries and some >> > >> >applications (especially in business databases) simply always use the 3 >> >letter coded. >> > >> > >> >This email was sent to you by Reuters, the global news and information company. >> >To find out more about Reuters visit www.about.reuters.com >> > >> >Any views expressed in this message are those of the individual sender, >> >except where the sender specifically states them to be the views of Reuters Ltd. >> >> >>#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University >>#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > >---Steve Deach > sdeach@adobe.com #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 24 16:15:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRaNP-0006vM-44; Sun, 24 Sep 2006 16:14:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRaNO-0006v2-5j for ltru@ietf.org; Sun, 24 Sep 2006 16:14:58 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRaNM-0002js-FP for ltru@ietf.org; Sun, 24 Sep 2006 16:14:57 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1488221nfc for ; Sun, 24 Sep 2006 13:14:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ojF9qm1HfqoIpvd7/iAdckAVIM7gcL5+5bT0jzpndtuw+5R7nYsZWZUJLplMEdzgwUPNFL3tHpUsdaVCAWi5veXM9H5ZxpyyURSWmtmpexNjHyVruC6qTfmO9oVcPSPRaJg8QrXJzl1SykGqU8LW/vxf0HLpx1sues0v/lrUASY= Received: by 10.49.94.20 with SMTP id w20mr645171nfl; Sun, 24 Sep 2006 13:14:55 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Sun, 24 Sep 2006 13:14:55 -0700 (PDT) Message-ID: <30b660a20609241314g2c885883g1c90b8ccb72ebcec@mail.gmail.com> Date: Sun, 24 Sep 2006 13:14:55 -0700 From: "Mark Davis" To: "Stephen Deach" In-Reply-To: <6.1.1.1.2.20060924074344.0212c5a0@namailhost.corp.adobe.com> MIME-Version: 1.0 References: <6.0.0.20.2.20060923112831.023f4d80@localhost> <6.1.1.1.2.20060923074520.02246bb0@namailhost.corp.adobe.com> <30b660a20609230931y3c7ed6bah38549885e72b1aa8@mail.gmail.com> <6.0.0.20.2.20060924113309.02411740@localhost> <6.1.1.1.2.20060924074344.0212c5a0@namailhost.corp.adobe.com> X-Google-Sender-Auth: 06c2904892819905 X-Spam-Score: 0.3 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Misha Wolf , www-international@w3.org, ltru@ietf.org Subject: [Ltru] Re: Updated article: Two-letter or three-letter language codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1295367529==" Errors-To: ltru-bounces@ietf.org --===============1295367529== Content-Type: multipart/alternative; boundary="----=_Part_23321_1850221.1159128895229" ------=_Part_23321_1850221.1159128895229 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 1. Details. >On the other hand, in the list, there are a few items (such as en-us, > >pt-br) that look perfectly fine. What was wrong with them? > > Capitalization. No. (trying for equal brevity) More completely: 102 0.015999% en-us. 122 0.010068% en-us As I said in my original message, the second one has a space at the end. The first one has a period at the end. So both are ill-formed. The same is true of pt-br (extra space at end). 2 Correction A correction: this is actually Accept-Language values, not documents -- we get different results looking at documents. A very interesting point, however, is that the errors here could be corrected if the browsers checked for well-formedness, or at least partial well-formedness, when allowing the user to pick his/er browser's language. That would eliminate a lot of cruft. 3. Guidance for User Agents. This raises a point we should probably have language in 4646bis for. Here's rough text for it; I anticipate that this will generate some discussion ;-) When a user agent, such as a browser, allows users to enter a language tag by typing, the results SHOULD be checked for well-formedness. If the user agent is not regularly updated to the latest registry, it SHOULD NOT require validity, because that could exclude current, valid language tags. It is recommended, however, that the user be notified that the language tag may not be valid. 4. Basic Well-Formedness. We may also want to have the notion of basic well-formedness, which that part of validity which can be checked with a regular expression. The difference is that basic well-formedness doesn't check for multiple singleton extensions. The value of doing this is that (a) it covers 99.999...% of the value of a well-formedness check, and (b) it is a much easier sell to implementers that all they need is a simple regex check. Mark ------=_Part_23321_1850221.1159128895229 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline 1. Details.

>On the other hand, in the list, there are a few items (such as en-us,
>pt-br) that look perfectly fine. What was wrong with them?

Capitalization.

No. (trying for equal brevity)

More completely:

102     0.015999%       en-us.
122     0.010068%       en-us

As I said in my original message, the second one has a space at the end. The first one has a period at the end. So both are ill-formed. The same is true of pt-br (extra space at end).

2 Correction

A correction: this is actually Accept-Language values, not documents -- we get different results looking at documents. A very interesting point, however, is that the errors here could be corrected if the browsers checked for well-formedness, or at least partial well-formedness, when allowing the user to pick his/er browser's language. That would eliminate a lot of cruft.

3. Guidance for User Agents. This raises a point we should probably have language in 4646bis for. Here's rough text for it; I anticipate that this will generate some discussion ;-)

When a user agent, such as a browser, allows users to enter a language tag by typing, the results SHOULD be checked for well-formedness. If the user agent is not regularly updated to the latest registry, it SHOULD NOT require validity, because that could exclude current, valid language tags. It is recommended, however, that the user be notified that the language tag may not be valid.

4. Basic Well-Formedness. We may also want to have the notion of basic well-formedness, which that part of validity which can be checked with a regular expression. The difference is that basic well-formedness doesn't check for multiple singleton extensions. The value of doing this is that (a) it covers 99.999...% of the value of a well-formedness check, and (b) it is a much easier sell to implementers that all they need is a simple regex check.

Mark

------=_Part_23321_1850221.1159128895229-- --===============1295367529== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1295367529==-- From ltru-bounces@ietf.org Sun Sep 24 17:15:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRbJa-0007T1-7m; Sun, 24 Sep 2006 17:15:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRbJZ-0007Sq-51 for ltru@ietf.org; Sun, 24 Sep 2006 17:15:05 -0400 Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRbJX-0000Po-QG for ltru@ietf.org; Sun, 24 Sep 2006 17:15:05 -0400 Received: from eupig2 (unverified [129.1.30.40]) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Sun, 24 Sep 2006 21:14:57 +0000 Received: from lonsmsxb01.emea.ime.reuters.com ([10.14.113.6]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31217) with ESMTP id <0J64009SQ8CYZ6@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Sun, 24 Sep 2006 21:14:58 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Sun, 24 Sep 2006 22:14:58 +0100 Date: Sun, 24 Sep 2006 22:14:57 +0100 From: Misha Wolf Subject: RE: [Ltru] To XML or not to XML To: ltru@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] To XML or not to XML Thread-Index: AcbekjAoD4A8C4z7QcmS5+EGdIxyPQBjEMRg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 24 Sep 2006 21:14:58.0412 (UTC) FILETIME=[7D6612C0:01C6E01E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 to XML as the *normative* registry format. Misha This email was sent to you by Reuters, the global news and information comp= any.=20 To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 24 21:43:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRfVF-0000aZ-PY; Sun, 24 Sep 2006 21:43:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRfVE-0000aQ-HJ for ltru@ietf.org; Sun, 24 Sep 2006 21:43:24 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRfVD-00016M-9x for ltru@ietf.org; Sun, 24 Sep 2006 21:43:24 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060925014320.CATN5459.mta9.adelphia.net@DGBP7M81>; Sun, 24 Sep 2006 21:43:20 -0400 Message-ID: <009d01c6e043$fbfcb0b0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <005201c6de07$d2c15220$6401a8c0@DGBP7M81> <2227.61.112.211.238.1158907925.squirrel@webmail.w3.mag.keio.ac.jp> <007901c6de40$f3154b10$6401a8c0@DGBP7M81> <2663.219.160.130.186.1158928079.squirrel@webmail.w3.mag.keio.ac.jp> <00aa01c6de4c$98eac000$6401a8c0@DGBP7M81> <45140CD6.7020109@yahoo-inc.com> Subject: Re: [Ltru] Re: To XML or not to XML Date: Sun, 24 Sep 2006 18:43:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > Applications would then be free to choose whichever copy of the > registry they wished, but the registration form and process would > remain unchanged, and, if any conflict were to arise, the record-jar > version of the registry would be authoritative. IMHO, ietf-languages needs to be as diligent as possible about preventing such conflicts from ever happening. This is why I suggested that IANA forward each updated Registry to the Reviewer for AUTH48-like verification *before* posting it publicly. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 24 22:00:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRflv-0000Ix-1l; Sun, 24 Sep 2006 22:00:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRflt-0000Ip-Og for ltru@ietf.org; Sun, 24 Sep 2006 22:00:37 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRfls-0004Xq-6S for ltru@ietf.org; Sun, 24 Sep 2006 22:00:37 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060925020029.CVHC5459.mta9.adelphia.net@DGBP7M81>; Sun, 24 Sep 2006 22:00:29 -0400 Message-ID: <009f01c6e046$61888fb0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 24 Sep 2006 19:00:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Michael Everson Subject: [Ltru] Re: 4646(bis) typo / issue (was: Status of draft-4645bis-00) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > The I-D will be a world record... :-) BTW, I propose that we fix > en-boont and en-scouse silently to "redundant" instead of > "grandfathered", the language subtag review list got that wrong. Thanks for catching this. We did forget to communicate that detail to IANA. I will work with the Reviewer to make sure that gets corrected. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 24 22:09:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRfu3-0004bI-Su; Sun, 24 Sep 2006 22:09:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRfu2-0004Yk-Sy for ltru@ietf.org; Sun, 24 Sep 2006 22:09:02 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRfu1-0005aQ-Ky for ltru@ietf.org; Sun, 24 Sep 2006 22:09:02 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060925020901.DGMW5459.mta9.adelphia.net@DGBP7M81> for ; Sun, 24 Sep 2006 22:09:01 -0400 Message-ID: <00a701c6e047$923737f0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 24 Sep 2006 19:09:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ltru] Re: 4646(bis) typo / issue X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > Yes, if the new variant is unrelated the tag better stays > grandfathered. Or let's just reserve the few pseudo-variants: either > they're registered matching the grandfathered tag, or they're off > limits. Nobody needs gaulish if it's not related to cel-gaulish etc. I reiterate my objection to enshrining administrative preferences like this in RFC 4646bis. John has already indicated that he doesn't intend to pursue this course for any other grandfathered tags: http://www.alvestrand.no/pipermail/ietf-languages/2006-August/004895.html Somebody might decide at some point that they do need 'gaulish' as a macrolanguage for Cisalpine and Transalpine, and this should not be forbidden out of hand. If it is never needed and nobody proposes it, no harm is done. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 24 22:19:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRg3b-0000np-Sj; Sun, 24 Sep 2006 22:18:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRg3a-0000iQ-Am for ltru@ietf.org; Sun, 24 Sep 2006 22:18:54 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRg3W-00074Z-3F for ltru@ietf.org; Sun, 24 Sep 2006 22:18:54 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GRg3T-0007kx-IW; Sun, 24 Sep 2006 22:18:47 -0400 Date: Sun, 24 Sep 2006 22:18:47 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: 4646(bis) typo / issue Message-ID: <20060925021847.GD8914@ccil.org> References: <00a701c6e047$923737f0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a701c6e047$923737f0$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > I reiterate my objection to enshrining administrative preferences like > this in RFC 4646bis. John has already indicated that he doesn't intend > to pursue this course for any other grandfathered tags: > > http://www.alvestrand.no/pipermail/ietf-languages/2006-August/004895.html Correct. I only proposed 'boont' and 'scouse' because they are in fact functioning as variant subtags and have legal syntax for variant subtags. Proposing them gets rid of them. The same is not true of any other case like 'xiang' or 'gaulish'. > Somebody might decide at some point that they do need 'gaulish' as a > macrolanguage for Cisalpine and Transalpine, and this should not be > forbidden out of hand. If it is never needed and nobody proposes it, no > harm is done. +1 -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Most languages are dramatically underdescribed, and at least one is dramatically overdescribed. Still other languages are simultaneously overdescribed and underdescribed. Welsh pertains to the third category. --Alan King _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 24 22:21:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRg5b-0001hk-UO; Sun, 24 Sep 2006 22:20:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRg5b-0001hf-Ea for ltru@ietf.org; Sun, 24 Sep 2006 22:20:59 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRg5Z-0007I2-6Y for ltru@ietf.org; Sun, 24 Sep 2006 22:20:59 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060925022056.XDRT14728.mta10.adelphia.net@DGBP7M81>; Sun, 24 Sep 2006 22:20:56 -0400 Message-ID: <00ad01c6e049$3c959bf0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 24 Sep 2006 19:20:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Misha Wolf , sdeach@adobe.com Subject: [Ltru] Re: Updated article: Two-letter or three-letter language codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: >> As a general process I always try to accept ill-formed input, but >> emit corrected output (since you pretty much have to grandfather all >> past formats). > > In the case of language tags, this is a very good policy for > interfaces between other systems and the Internet protocols and > formats that use RFC 4646 language tags. Martin is right in the sense that a process can decide to accept "eng" or "English" or something else, and convert it to "en". This is not the same, though, as interpreting BCP 47 (RFC 4646) as permitting "eng" or "English" as a valid synonym for "en". All applications that claim conformance to BCP 47 must use the Language Subtag Registry as the complete catalog of non-private-use subtags. Thinking in terms of "2-letter ISO codes" and "3-letter ISO codes" is fine for applications that do not claim conformance to BCP 47. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 24 23:45:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRhPA-0007uC-Qc; Sun, 24 Sep 2006 23:45:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRhP9-0007u2-Gd for ltru@lists.ietf.org; Sun, 24 Sep 2006 23:45:15 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRhP6-0008IF-3m for ltru@lists.ietf.org; Sun, 24 Sep 2006 23:45:15 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GRhP4-0006W5-3f for ltru@lists.ietf.org; Mon, 25 Sep 2006 05:45:10 +0200 Received: from pd9fba931.dip0.t-ipconnect.de ([217.251.169.49]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Sep 2006 05:45:10 +0200 Received: from nobody by pd9fba931.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Sep 2006 05:45:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 25 Sep 2006 05:44:07 +0200 Organization: Lines: 24 Message-ID: <45175087.50FB@xyzzy.claranet.de> References: <00a701c6e047$923737f0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba931.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] Re: 4646(bis) typo / issue X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Somebody might decide at some point that they do need > 'gaulish' as a macrolanguage for Cisalpine and Transalpine, > and this should not be forbidden out of hand. Reserving the bogus variants has nothing to do with language subtags. If "macrolanguage" is defined as the first subtag in a prefix of a registered extlang, then "gaulish" will never be a macrolanguage, all language subtags of extlang prefixes are limited to 2 or 3 letters. > If it is never needed and nobody proposes it, no harm is > done. We've seen that the rule how grandfathered crap can mutate into redundant tags was harmful in the latest registry. Eliminating that possibility by reserving the last five "pseudo-variants" gaulish / guoyu / hakka / lobjan / xiang is attractive - if the reservation prose is less convoluted than the existing mutation prose. As a mere implementation detail it's less interesting. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 24 23:54:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRhXi-0003Q8-4H; Sun, 24 Sep 2006 23:54:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRhXh-0003OX-Jn for ltru@ietf.org; Sun, 24 Sep 2006 23:54:05 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRhXf-0000cQ-CO for ltru@ietf.org; Sun, 24 Sep 2006 23:54:05 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GRhXf-00065Z-16; Sun, 24 Sep 2006 23:54:03 -0400 Date: Sun, 24 Sep 2006 23:54:03 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: 4646(bis) typo / issue Message-ID: <20060925035402.GF8914@ccil.org> References: <00a701c6e047$923737f0$6401a8c0@DGBP7M81> <45175087.50FB@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45175087.50FB@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > Reserving the bogus variants has nothing to do with language > subtags. If "macrolanguage" is defined as the first subtag in > a prefix of a registered extlang, then "gaulish" will never be > a macrolanguage, all language subtags of extlang prefixes are > limited to 2 or 3 letters. Being a registered prefix of an extlang is a syntactic property; being a macrolanguage is a semantic property. A macrolanguage can be introduced that covers two existing individual languages, but that doesn't mean we change the tagging for the existing individual languages (as we decided a few weeks ago). Therefore, someone could request 'gaulish' as an IETF-registered language subtag for the Gaulish macrolanguage in order to tag Gaulish documents where the Cisalpine/Transalpine distinction is not important. If we block 'gaulish' as a subtag, that can't happen even if it's useful. -- John Cowan cowan@ccil.org http://ccil.org/~cowan If I have not seen as far as others, it is because giants were standing on my shoulders. --Hal Abelson _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 25 00:27:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRi3Z-0002fV-Uj; Mon, 25 Sep 2006 00:27:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRVPk-0008I5-6u for ltru@ietf.org; Sun, 24 Sep 2006 10:57:04 -0400 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRVPj-0007Tb-0S for ltru@ietf.org; Sun, 24 Sep 2006 10:57:04 -0400 Received: from localhost (localhost [127.0.0.1]) by homer.w3.org (Postfix) with ESMTP id 8C1344F6EA; Sun, 24 Sep 2006 10:56:59 -0400 (EDT) Date: Sun, 24 Sep 2006 16:56:56 +0200 From: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <1251513090.20060924165656@w3.org> To: Stephen Deach In-Reply-To: <6.1.1.1.2.20060924074344.0212c5a0@namailhost.corp.adobe.com> References: <6.0.0.20.2.20060923112831.023f4d80@localhost> <6.1.1.1.2.20060923074520.02246bb0@namailhost.corp.adobe.com> <30b660a20609230931y3c7ed6bah38549885e72b1aa8@mail.gmail.com> <6.0.0.20.2.20060924113309.02411740@localhost> <6.1.1.1.2.20060924074344.0212c5a0@namailhost.corp.adobe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-Mailman-Approved-At: Mon, 25 Sep 2006 00:26:59 -0400 Cc: ltru@ietf.org, Misha Wolf , www-international@w3.org Subject: [Ltru] Re: Updated article: Two-letter or three-letter language codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Chris Lilley List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sunday, September 24, 2006, 4:44:03 PM, Stephen wrote: SD> At 2006.09.24-11:56(+0900), Martin Duerst wrote: >>Hello Mark, >>Many thanks for this interesting data. In my mailer, the line endings >>didn't work very well, so I refomatted it (at the same time, my >>mailer messed up the non-ASCII stuff, sorry). >>The only three-letter code I can see is pdf, for which we can blame >>Steve's company :-). >>On the other hand, in the list, there are a few items (such as en-us, >>pt-br) that look perfectly fine. What was wrong with them? SD> Capitalization. Capitalization is, IIRC, irrelevant. However "en-us." and "en-us " (note trailing space and trailing period) are not correct. en-US or En-Us or any other variant therof are fine. >> >(the second one has a space at the end. this also excludes x-.... >> >where the ... is a subtag longer than 8 -- that has a pretty high >> >frequency) >> >Rank Frequency tag >> >102 0.015999% en-us. >> >122 0.010068% en-us -- Chris Lilley mailto:chris@w3.org Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 25 00:27:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRi3a-0002fZ-19; Mon, 25 Sep 2006 00:27:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRVUV-0001mK-6E for ltru@ietf.org; Sun, 24 Sep 2006 11:01:59 -0400 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRVUT-0007mX-RT for ltru@ietf.org; Sun, 24 Sep 2006 11:01:59 -0400 Received: from localhost (localhost [127.0.0.1]) by homer.w3.org (Postfix) with ESMTP id AB3294F6EA; Sun, 24 Sep 2006 11:01:56 -0400 (EDT) Date: Sun, 24 Sep 2006 17:01:54 +0200 From: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <108959705.20060924170154@w3.org> To: Stephen Deach In-Reply-To: <6.1.1.1.2.20060924075111.020ad4e8@namailhost.corp.adobe.com> References: <6.0.0.20.2.20060923112831.023f4d80@localhost> <6.1.1.1.2.20060923074520.02246bb0@namailhost.corp.adobe.com> <30b660a20609230931y3c7ed6bah38549885e72b1aa8@mail.gmail.com> <6.0.0.20.2.20060924113309.02411740@localhost> <6.1.1.1.2.20060924075111.020ad4e8@namailhost.corp.adobe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Mon, 25 Sep 2006 00:26:59 -0400 Cc: ltru@ietf.org, Misha Wolf , www-international@w3.org Subject: [Ltru] Re: Updated article: Two-letter or three-letter language codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Chris Lilley List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sunday, September 24, 2006, 4:54:45 PM, Stephen wrote: SD> The fact that "utf-8" and "pdf" (which I would call "encodings") show up in SD> this list points out something interesting about the term "language" that SD> should probably be emphasized in the paper/article. I agree. The fact that "Chinese" and "Indonesian" show up is less surprising but should also be explained as being incorrect, and the correct way for those should be given in examples. -- Chris Lilley mailto:chris@w3.org Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 25 01:07:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRig5-0004PH-06; Mon, 25 Sep 2006 01:06:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRifa-00045r-8e for ltru@ietf.org; Mon, 25 Sep 2006 01:06:18 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRiRc-00067F-II for ltru@ietf.org; Mon, 25 Sep 2006 00:51:53 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060925045147.BODZ14728.mta10.adelphia.net@DGBP7M81> for ; Mon, 25 Sep 2006 00:51:47 -0400 Message-ID: <00e101c6e05e$4f880620$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 24 Sep 2006 21:51:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ltru] Re: 4646(bis) typo / issue X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> If it is never needed and nobody proposes it, no harm is done. > > We've seen that the rule how grandfathered crap can mutate into > redundant tags was harmful in the latest registry. Eliminating that > possibility by reserving the last five "pseudo-variants" gaulish / > guoyu / hakka / lobjan / xiang is attractive - if the reservation > prose is less convoluted than the existing mutation prose. As a mere > implementation detail it's less interesting. In what way was the registration of variants 'boont' and 'scouse' harmful? What or who was harmed? -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 25 03:01:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRkTJ-0004Kr-7I; Mon, 25 Sep 2006 03:01:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRkTI-0004Hp-1b for ltru@lists.ietf.org; Mon, 25 Sep 2006 03:01:44 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRkRk-0003cg-1u for ltru@lists.ietf.org; Mon, 25 Sep 2006 03:00:09 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GRkRd-0007Fz-Lt for ltru@lists.ietf.org; Mon, 25 Sep 2006 09:00:01 +0200 Received: from pd9fba931.dip0.t-ipconnect.de ([217.251.169.49]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Sep 2006 09:00:01 +0200 Received: from nobody by pd9fba931.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Sep 2006 09:00:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 25 Sep 2006 08:56:11 +0200 Organization: Lines: 22 Message-ID: <45177D8B.445A@xyzzy.claranet.de> References: <00e101c6e05e$4f880620$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba931.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] Re: 4646(bis) typo / issue X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > What or who was harmed? The integrity of the registry until it's fixed. But it helped me to find a bug in my XML-converter, a reference to a variant subtag must not collide with a language subtag of length 5..8 like the hypothetical "gaulish". Adding underscores to _all_ non-primary subtag IDs (not only those starting with a digit) would work until 4646bis-00. But not for 4646bis-01, where the Preferred-Value of an extlang can be a language. Odd situation: Language subtags of length 3 use the same namsepace as extlang subtags. Language subtags of length 5..8 do NOT use the same namespace as variant subtags. For case insensitive operations they also don't use the namespaces of region or script subtags. Apparently my registry converter needs its own minimal parser to get this right... _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 25 03:02:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRkTy-000505-UR; Mon, 25 Sep 2006 03:02:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRkTJ-0004BK-WF for ltru@lists.ietf.org; Mon, 25 Sep 2006 03:01:46 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRkQI-0003LT-Gr for ltru@lists.ietf.org; Mon, 25 Sep 2006 02:58:39 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GRkPs-0006q2-EN for ltru@lists.ietf.org; Mon, 25 Sep 2006 08:58:12 +0200 Received: from pd9fba931.dip0.t-ipconnect.de ([217.251.169.49]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Sep 2006 08:58:12 +0200 Received: from nobody by pd9fba931.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Sep 2006 08:58:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 25 Sep 2006 07:03:04 +0200 Organization: Lines: 11 Message-ID: <45176308.35F1@xyzzy.claranet.de> References: <00a701c6e047$923737f0$6401a8c0@DGBP7M81> <45175087.50FB@xyzzy.claranet.de> <20060925035402.GF8914@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba931.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Ltru] Re: 4646(bis) typo / issue X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > someone could request 'gaulish' as an IETF-registered > language subtag Yes, but that's no problem wrt cel-gaulish, the "reservation" idea was about variant subtags, not language subtags. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 25 03:16:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRkh3-00033S-Tg; Mon, 25 Sep 2006 03:15:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRkh2-00033N-Om for ltru@ietf.org; Mon, 25 Sep 2006 03:15:56 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRkgy-0005Hf-Fd for ltru@ietf.org; Mon, 25 Sep 2006 03:15:56 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 03C8526C202; Mon, 25 Sep 2006 09:15:52 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 1A96E26C1F5; Mon, 25 Sep 2006 09:15:51 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 0C49B58ED24; Mon, 25 Sep 2006 09:15:51 +0200 (CEST) Date: Mon, 25 Sep 2006 09:15:51 +0200 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20060925071551.GA1140@nic.fr> References: <001801c6b84d$144cd510$040aa8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001801c6b84d$144cd510$040aa8c0@DGBP7M81> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: LTRU Working Group Subject: [Ltru] Available parsers? (Was: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, Aug 04, 2006 at 10:07:40PM -0700, Doug Ewell wrote a message of 30 lines which said: > 2. Five was being generous. I know I have one and Addison has one, > and I think Mark put one together for demonstration purposes than > was about 98% complete, and now yours. BTW, are any of these "language tag parsers" available to the public? May be not as free software but at last with source to read it and learn from it and see in what programming language they are and discover potential interoperability problems? Mine is here: http://www.bortzmeyer.org/gabuzomeu-parsing-language-tags.html _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 25 09:04:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRq8S-0003EU-1u; Mon, 25 Sep 2006 09:04:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRq8R-0003EJ-9C for ltru@ietf.org; Mon, 25 Sep 2006 09:04:35 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRq8P-0004YC-MS for ltru@ietf.org; Mon, 25 Sep 2006 09:04:35 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060925130433.KRIJ14728.mta10.adelphia.net@DGBP7M81>; Mon, 25 Sep 2006 09:04:33 -0400 Message-ID: <00c201c6e0a3$25a9bd90$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <001801c6b84d$144cd510$040aa8c0@DGBP7M81> <20060925071551.GA1140@nic.fr> Date: Mon, 25 Sep 2006 06:04:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] Re: Available parsers? (Was: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > BTW, are any of these "language tag parsers" available to the public? > May be not as free software but at last with source to read it and > learn from it and see in what programming language they are and > discover potential interoperability problems? I still need to wrap mine in an installer package of some sort and write a proper Web page about it. It's in Visual C++ 6.0. I haven't decided whether to distribute the source, but the exe will be free. > Mine is here: > http://www.bortzmeyer.org/gabuzomeu-parsing-language-tags.html I'm having extreme trouble viewing that page in IE 7.0. By reading the HTML source, I was able to find the URL for downloading. I'll take a look at the source, though it'll be a slow process as I've never seen Haskell before. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 25 11:13:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRs9Q-00024g-42; Mon, 25 Sep 2006 11:13:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRs9O-00024W-QO for ltru@ietf.org; Mon, 25 Sep 2006 11:13:42 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRs9N-0004bS-E3 for ltru@ietf.org; Mon, 25 Sep 2006 11:13:42 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060925151336.BAYT5459.mta9.adelphia.net@DGBP7M81> for ; Mon, 25 Sep 2006 11:13:36 -0400 Message-ID: <011e01c6e0b5$2d450c00$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 25 Sep 2006 08:13:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Subject: [Ltru] Re: 4646(bis) typo / issue X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> What or who was harmed? > > The integrity of the registry until it's fixed. There is no restriction that a tag may not be grandfathered if it is syntactically eligible to be converted into a generative tag consisting of valid subtags, nor that the subtags may not subsequently be registered. That was a difficult sentence to write, and probably to read, so let's try again: The fact that 'en' is a valid subtag, and 'boont' could have been, does not mean there cannot be a grandfathered tag "en-boont". Similarly, the fact that "en-boont" existed does not mean 'boont' could not then be registered, making "en-boont" redundant. RFC 4646, Section 2.2.1, item 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) [Tags that start with a valid primary language subtag may still be grandfathered.] Section 2.2.2: Example: In a future revision or update of this document, the tag "zh-gan" (registered under RFC 3066) might become a valid non-grandfathered (that is, redundant) tag in which the subtag 'gan' might represent the Chinese dialect 'Gan'. [Grandfathered tags may subsequently become redundant.] Section 2.2.8: Grandfathered tags contain one or more subtags that are not defined in the Language Subtag Registry (see Section 3). Redundant tags consist entirely of subtags defined above and whose independent registration is superseded by this document. [Does not say the undefined subtags cannot later be registered.] Section 3.3: The grandfathered entries include those that can never be legal under those same provisions. [Does not say *only* those that can never be legal.] Records of type 'grandfathered' MAY have their type converted to 'redundant': see item 12 in Section 3.6 [recte: 3.4] for more information. Section 3.4, item 12: Stability provisions apply to grandfathered tags with this exception: should all of the subtags in a grandfathered tag become valid subtags in the IANA registry, 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, if the subtag 'gan' in the language tag "zh-gan" were to be registered as an extended language subtag, then the grandfathered tag "zh-gan" would be deprecated (but existing content or implementations that use "zh-gan" would remain valid). [Does not say this cannot happen by registering a variant.] Section 3.6: Subtags proposed for registration that would cause all or part of a grandfathered tag to become redundant but whose meaning conflicts with or alters the meaning of the grandfathered tag MUST be rejected. [Not the case here.] RFC 4645, Section 2, item 8: Tags in the [RFC3066] registry that contained one or more subtags that either did not match the valid registration pattern or were not otherwise defined by [RFC4646] were converted to corresponding records of type "grandfathered" in the ILSR. These records cannot become type "redundant" except by revision of [RFC4646], but may have a "Deprecated" and "Preferred-Value" field added to them if a subsequent subtag assignment or combination of assignments renders the tag obsolete. Section 2, item 11: All remaining [RFC3066] registered tags were converted to records of type "grandfathered" in the ILSR. Interested parties may use the registration process in [RFC4646] to attempt to register the variant subtags not already present in the Language Subtag Registry. If all of the subtags in the original tag become fully defined by the resulting registrations, then the original tag is superseded. Such tags will have their record changed from type "grandfathered" to type "redundant" in the registry. Note that previous approval of a tag under [RFC3066] is not a guarantee of approval of a variant subtag under [RFC4646]. The existing [RFC3066] tag maintains its validity, but the original reason for its registration might have become obsolete. [Describes exactly the present situation.] I don't see it written anyplace that there is an integrity problem. There may be an implementation problem if applications make an unwarranted assumption, that grandfathered tags cannot consist of a well-formed sequence of subtags, but that is not supported by the RFCs. > But it helped me to find a bug in my XML-converter, a reference to a > variant subtag must not collide with a language subtag of length 5..8 > like the hypothetical "gaulish". There is no namespace collision between language and variant subtags. I made a misstatement earlier about somebody needing to register 'gaulish' as a macrolanguage; I should have said "as an umbrella term" when the distinction between Cisalpine and Transalpine is unimportant or it is unknown which language is present. (Both have been extinct for 1,500+ years and the primary difference was regional, so this scenario is plausible.) > Adding underscores to _all_ non-primary subtag IDs (not only those > starting with a digit) would work until 4646bis-00. But not for > 4646bis-01, where the Preferred-Value of an extlang can be a language. > Odd situation: > > Language subtags of length 3 use the same namsepace as extlang > subtags. Language subtags of length 5..8 do NOT use the same > namespace as variant subtags. For case insensitive operations they > also don't use the namespaces of region or script subtags. While primary and extended language subtags do occupy the same namespace, I'm not sure there is any reason a parser needs to care about this. > Apparently my registry converter needs its own minimal parser to get > this right... -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 25 11:49:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsiP-0008VU-SW; Mon, 25 Sep 2006 11:49:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsiN-0008QZ-I9 for ltru@ietf.org; Mon, 25 Sep 2006 11:49:52 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRsiJ-0002Oz-QV for ltru@ietf.org; Mon, 25 Sep 2006 11:49:51 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1672267nfc for ; Mon, 25 Sep 2006 08:49:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=DqQa9gcZoYkqobSreVxYml9Q/rsDQreBxpksoubf0P/7Pk0IjpGZwrnN0fHNYjAN88XFgQ7n0GISzZlcbnaUI+FbH2/u8aN8Gd0hGeDWskFrmavIJkUw71LPtlmfHqVHpgA751gX45Ppou1JgdRBMH+RqcE5C6aQZYNu379vm1o= Received: by 10.49.41.18 with SMTP id t18mr1636507nfj; Mon, 25 Sep 2006 08:49:46 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Mon, 25 Sep 2006 08:49:46 -0700 (PDT) Message-ID: <30b660a20609250849k455115ci4ca24ebfcb175c2c@mail.gmail.com> Date: Mon, 25 Sep 2006 08:49:46 -0700 From: "Mark Davis" To: "LTRU Working Group" MIME-Version: 1.0 X-Google-Sender-Auth: 68b84d01e372645d X-Spam-Score: 0.5 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Subject: [Ltru] Process X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1673753361==" Errors-To: ltru-bounces@ietf.org --===============1673753361== Content-Type: multipart/alternative; boundary="----=_Part_11973_9174225.1159199386612" ------=_Part_11973_9174225.1159199386612 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline We clearly need some more process in the spec -- I didn't realize, for example, that the armenian tags were added. Here is a very rough draft revision of 3.2/3.3, incorporating some ideas that we've discussed at various times. 3.2. Language Subtag Review Board The Language Subtag Board (LSB) consists of three Language Subtag Reviewers. Each of the Language Subtag Reviewers.must read and thoroughly understand all parts of BCP 47. All decisions of the LSB are by a majority vote. The Language Subtag Board is appointed by the IESG for an indefinite term, subject to removal or replacement at the IESG's discretion. Any instance where the LSB does not follow the procedures in this document are grounds for dismissal by the IESG. The Language Subtag Board moderates the ietf-languages mailing list, responds to requests for registration, and performs the other registry maintenance duties described in Section 3.3 (Maintenance of the Registry). Only the Language Subtag Board is permitted to request IANA to change, update or add records to the Language Subtag Registry. The performance or decisions of the Language Subtag Board MAY be appealed to the IESG under the same rules as other IETF decisions (see [RFC2026] (Bradner, S., "The Internet Standards Process -- Revision 3," October 1996.)). The IESG can reverse or overturn the decision of the Language Subtag Board, provide guidance, or take other appropriate actions. Because of the need for stability, however, once a change is posted to http://www.iana.org/assignments/language-subtag-registry, it is irrevocable. 3.3. Maintenance of the Registry Maintenance of the registry requires that as codes are assigned or withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language Subtag Board MUST evaluate each change, determine whether it conflicts with existing registry entries, and within 30 days propose a change to the registry as described in Section 3.5. The Language Subtag Board MUST ensure that all new subtags meet the requirements in Section 4.1 (Choice of Language Tag)or submit an appropriate alternate subtag as described in that section. The Language Subtag Board MUST respond within 15 days to any language subtag request form. The response MUST go both to the submitter, and to the Language Tag Registry Mailing List. The response MUST indicate whether the request is accepted, or not accepted. If it is not accepted, the Language Subtag Board MUST indicate which clauses of BCP 47 would be violated by acceptance, and which changes to the language subtag request form would make it acceptable. Upon acceptance, the Language Subtag Board MUST incorporate corresponding changes into a public Draft Language Tag Registry, having precisely the same syntax as http://www.iana.org/assignments/language-subtag-registry, and notify the Language Tag Registry Mailing List. During a 15-day review period, people have the opportunity to review the syntax of the change, and the Language Subtag Board may make changes in response to feedback. Any such change starts the 15-day review period anew. Once the review period has completed, the LSB will change the File-Date and forward the entire file to IANA for posting within 7 days. Once IANA has posted the file, IANA MUST send a message will be sent to the Language Tag Registry Mailing List acknowledging that. [Move the following to a section on the form] If a record represents a new subtag that does not currently exist in the registry, then the message's subject line MUST include the word "INSERT". If the record represents a change to an existing subtag, then the subject line of the message MUST include the word "MODIFY". The message MUST contain both the record for the subtag being inserted or modified and the new File-Date record. Here is an example of what the body of the message might contain: 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 Section 3.6 (Possibilities for Registration)for more information. The decision making process about which tags were initially grandfathered and which were made redundant is described in [initial-registry] (Ewell, D., Ed., "Initial Language Subtag Registry," June 2005.) . Whenever an entry is created or modified in the registry, the 'File-Date' record at the start of the registry is updated to reflect the most recent modification date in the [RFC3339] (Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps," July 2002.)"full-date" format. Before forwarding a new registration to IANA, the Language Subtag Reviewer MUST ensure that values in the 'Subtag' field match case according to the description in Section 3.1 (Format of the IANA Language Subtag Registry). ------=_Part_11973_9174225.1159199386612 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline We clearly need some more process in the spec -- I didn't realize, for example, that the armenian tags were added.

Here is a very rough draft revision of 3.2/3.3, incorporating some ideas that we've discussed at various times.

3.2. Language Subtag Review Board

The Language Subtag Board (LSB) consists of three Language Subtag Reviewers. Each of the Language Subtag Reviewers.must read and thoroughly understand all parts of BCP 47. All decisions of the LSB are by a majority vote. The Language Subtag Board is appointed by the IESG for an indefinite term, subject to removal or replacement at the IESG's discretion. Any instance where the LSB does not follow the procedures in this document are grounds for dismissal by the IESG.

The Language Subtag Board moderates the ietf-languages mailing list, responds to requests for registration, and performs the other registry maintenance duties described in Section 3.3 (Maintenance of the Registry ). Only the Language Subtag Board is permitted to request IANA to change, update or add records to the Language Subtag Registry.

The performance or decisions of the Language Subtag Board MAY be appealed to the IESG under the same rules as other IETF decisions (see [RFC2026] (Bradner, S., "The Internet Standards Process -- Revision 3," October 1996. )). The IESG can reverse or overturn the decision of the Language Subtag Board, provide guidance, or take other appropriate actions. Because of the need for stability, however, once a change is posted to http://www.iana.org/assignments/language-subtag-registry, it is irrevocable.

3.3. Maintenance of the Registry

Maintenance of the registry requires that as codes are assigned or withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language Subtag Board MUST evaluate each change, determine whether it conflicts with existing registry entries, and within 30 days propose a change to the registry as described in Section 3.5.

The Language Subtag Board MUST ensure that all new subtags meet the requirements in Section 4.1 (Choice of Language Tag) or submit an appropriate alternate subtag as described in that section. The Language Subtag Board MUST respond within 15 days to any language subtag request form. The response MUST go both to the submitter, and to the Language Tag Registry Mailing List. The response MUST indicate whether the request is accepted, or not accepted. If it is not accepted, the Language Subtag Board MUST indicate which clauses of BCP 47 would be violated by acceptance, and which changes to the language subtag request form would make it acceptable.

Upon acceptance, the Language Subtag Board MUST incorporate corresponding changes into a public Draft Language Tag Registry, having precisely the same syntax as http://www.iana.org/assignments/language-subtag-registry, and notify the Language Tag Registry Mailing List. During a 15-day review period, people have the opportunity to review the syntax of the change, and the Language Subtag Board may make changes in response to feedback. Any such change starts the 15-day review period anew. Once the review period has completed, the LSB will change the File-Date and forward the entire file to IANA for posting within 7 days. Once IANA has posted the file, IANA MUST send a message will be sent to the Language Tag Registry Mailing List acknowledging that.


[Move the following to a section on the form]

If a record represents a new subtag that does not currently exist in the registry, then the message's subject line MUST include the word "INSERT". If the record represents a change to an existing subtag, then the subject line of the message MUST include the word "MODIFY". The message MUST contain both the record for the subtag being inserted or modified and the new File-Date record. Here is an example of what the body of the message might contain:

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 Section 3.6 (Possibilities for Registration ) for more information. The decision making process about which tags were initially grandfathered and which were made redundant is described in [initial-registry] ( Ewell, D., Ed., "Initial Language Subtag Registry," June 2005.).

Whenever an entry is created or modified in the registry, the 'File-Date' record at the start of the registry is updated to reflect the most recent modification date in the [RFC3339] (Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps," July 2002. ) "full-date" format.

Before forwarding a new registration to IANA, the Language Subtag Reviewer MUST ensure that values in the 'Subtag' field match case according to the description in Section 3.1 (Format of the IANA Language Subtag Registry ).

------=_Part_11973_9174225.1159199386612-- --===============1673753361== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1673753361==-- From ltru-bounces@ietf.org Mon Sep 25 13:40:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRuRi-0001Ft-Ob; Mon, 25 Sep 2006 13:40:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRuRh-0001Fj-06 for ltru@ietf.org; Mon, 25 Sep 2006 13:40:45 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRuRb-0004md-LY for ltru@ietf.org; Mon, 25 Sep 2006 13:40:44 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060925174039.LUEJ5459.mta9.adelphia.net@DGBP7M81>; Mon, 25 Sep 2006 13:40:39 -0400 Message-ID: <016201c6e0c9$b7d7cf60$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 25 Sep 2006 10:40:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Subject: [Ltru] Re: Process X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Disclaimer: I may have a conflict of interest in discussing Mark's proposal below, since it would likely turn my "behind the scenes" role into an Official Board Membership. Mark Davis wrote: > 3.2. Language Subtag Review Board In general, I support this proposal. A few specific comments follow. > Any instance where the LSB does not follow the procedures in this > document are grounds for dismissal by the IESG. "Any instance"... "is" > The IESG can reverse or overturn the decision of the Language Subtag > Board, provide guidance, or take other appropriate actions. I don't understand the difference between reversing a decision and overturning it. This wording is also in RFC 4646. > Because of the need for stability, however, once a change is posted to > http://www.iana.org/assignments/language-subtag-registry, it is > irrevocable. In that case, we will *really* need the mechanism proposed below whereby we make the actual changes, and IANA merely posts the new file. With the current system, we need to be able to correct errors. We may still need a provision to correct flagrant syntactical errors, such as a "Type" field being omitted. We should also have some assurance that what IANA received is the same as what we sent -- for instance, by providing them an MD5 as Martin suggested for 4645bis. > Maintenance of the registry requires that as codes are assigned or > withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language > Subtag Board MUST evaluate each change, determine whether it conflicts > with existing registry entries, and within 30 days propose a change to > the registry as described in Section 3.5. > ... > The Language Subtag Board MUST respond within 15 days to any language > subtag request form. I would like to see some provision for limited extension of these 30-day and 15-day limits, in case one or more of the Reviewers is absent or unavailable, preventing the two-thirds majority vote. I can easily imagine a problem arising if a request is filed in early to mid-December. > Upon acceptance, the Language Subtag Board MUST incorporate > corresponding changes into a public Draft Language Tag Registry, > having precisely the same syntax as > http://www.iana.org/assignments/language-subtag-registry, and notify > the Language Tag Registry Mailing List. This should specify that this is the ietf-languages list, not the LTRU WG (which will not be around forever). Also, replace "Tag" with "Subtag". > During a 15-day review period, people have the opportunity to review > the syntax of the change, and the Language Subtag Board may make > changes in response to feedback. Any such change starts the 15-day > review period anew. Excellent. > Once the review period has completed, the LSB will change the > File-Date and forward the entire file to IANA for posting within 7 > days. Then I don't think it should be necessary for the registration form (which would now be processed solely by the LSB, not IANA) to contain a File-Date which will only be overridden. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 25 14:24:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRv81-00084f-UY; Mon, 25 Sep 2006 14:24:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRv80-00084Z-Jc for ltru@ietf.org; Mon, 25 Sep 2006 14:24:28 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRv7s-0002cB-I9 for ltru@ietf.org; Mon, 25 Sep 2006 14:24:28 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004777716.msg for ; Mon, 25 Sep 2006 19:25:32 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Mon, 25 Sep 2006 19:23:52 +0100 From: "Debbie Garside" To: "'LTRU Working Group'" Subject: RE: [Ltru] Process Date: Mon, 25 Sep 2006 19:23:29 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: Acbgun/XyO5i7qoySI2UvhPScrSkWQAEh1ww In-Reply-To: <30b660a20609250849k455115ci4ca24ebfcb175c2c@mail.gmail.com> Message-ID: <3B4E8BD05FDB439B9EA0BAD65D25B19C.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Mon, 25 Sep 2006 19:25:32 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Mon, 25 Sep 2006 19:25:32 +0100 X-Spam-Score: 0.1 (/) X-Scan-Signature: 56904003e9d74831849863e83b1962ec Cc: 'Doug Ewell' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1175660606==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1175660606== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E5_01C6E0D8.15287AD0" This is a multi-part message in MIME format. ------=_NextPart_000_00E5_01C6E0D8.15287AD0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Mark wrote wrt: > We clearly need some more process in the spec -- I didn't realize, for example, that the armenian tags were added. I am not sure that I saw the registration forms being submitted for inclusion into the Registry... > 3.2. Language Subtag Review Board In essence, I very much like it, although I have not yet looked at the detailed wording. However, I would propose the following change from: ---- > Any instance where the LSB does not follow the procedures in this > document are grounds for dismissal by the IESG. ----- To ----- Any instance where the LSB does not follow the procedures in this document MAY be considered as grounds for dismissal by the IESG. ---- I think we need to allow for human error. A simple human error which can be corrected should not be grounds for dismissal unless it is truly considered to be negligence on the part of the LSRB. In response to Doug where he wrote: > I would like to see some provision for limited extension of these 30-day and 15-day limits, in case one or more of the Reviewers is absent or unavailable, > preventing the two-thirds majority vote. I can easily imagine a problem arising if a request is filed in early to mid-December. One Reviewer can be unavailable. You would still have a majority vote; thus only two Reviewers are ever required to action changes. However, there could be a situation where two (or even 3) Reviewers were unavailable (unlikely I know) but maybe some wording to say that the LSRB can advise the list of a time extension where deemed necessary. Necessary can be defined as being where two or more Reviewers are absent. On another note, to protect the Registry from requests that may be made by people with "ulterior motives" I also think it might be appropriate to state that x number (for instance 5) of people need to show support for additions to the Registry that do not form part of the underlying ISO/UN standards. But I am not completely hung up on this; although it could also encourage people to comment more often which can only be good. Best regards Debbie Garside _____ From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: 25 September 2006 16:50 To: LTRU Working Group Subject: [Ltru] Process We clearly need some more process in the spec -- I didn't realize, for example, that the armenian tags were added. Here is a very rough draft revision of 3.2/3.3, incorporating some ideas that we've discussed at various times. 3.2. Language Subtag Review Board The Language Subtag Board (LSB) consists of three Language Subtag Reviewers. Each of the Language Subtag Reviewers.must read and thoroughly understand all parts of BCP 47. All decisions of the LSB are by a majority vote. The Language Subtag Board is appointed by the IESG for an indefinite term, subject to removal or replacement at the IESG's discretion. Any instance where the LSB does not follow the procedures in this document are grounds for dismissal by the IESG. The Language Subtag Board moderates the ietf-languages mailing list, responds to requests for registration, and performs the other registry maintenance duties described in Section 3.3 (Maintenance of the Registry ). Only the Language Subtag Board is permitted to request IANA to change, update or add records to the Language Subtag Registry. The performance or decisions of the Language Subtag Board MAY be appealed to the IESG under the same rules as other IETF decisions (see [RFC2026] (Bradner, S., "The Internet Standards Process -- Revision 3," October 1996. )). The IESG can reverse or overturn the decision of the Language Subtag Board, provide guidance, or take other appropriate actions. Because of the need for stability, however, once a change is posted to http://www.iana.org/assignments/language-subtag-registry, it is irrevocable. 3.3. Maintenance of the Registry Maintenance of the registry requires that as codes are assigned or withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language Subtag Board MUST evaluate each change, determine whether it conflicts with existing registry entries, and within 30 days propose a change to the registry as described in Section 3.5. The Language Subtag Board MUST ensure that all new subtags meet the requirements in Section 4.1 (Choice of Language Tag) or submit an appropriate alternate subtag as described in that section. The Language Subtag Board MUST respond within 15 days to any language subtag request form. The response MUST go both to the submitter, and to the Language Tag Registry Mailing List. The response MUST indicate whether the request is accepted, or not accepted. If it is not accepted, the Language Subtag Board MUST indicate which clauses of BCP 47 would be violated by acceptance, and which changes to the language subtag request form would make it acceptable. Upon acceptance, the Language Subtag Board MUST incorporate corresponding changes into a public Draft Language Tag Registry, having precisely the same syntax as http://www.iana.org/assignments/language-subtag-registry, and notify the Language Tag Registry Mailing List. During a 15-day review period, people have the opportunity to review the syntax of the change, and the Language Subtag Board may make changes in response to feedback. Any such change starts the 15-day review period anew. Once the review period has completed, the LSB will change the File-Date and forward the entire file to IANA for posting within 7 days. Once IANA has posted the file, IANA MUST send a message will be sent to the Language Tag Registry Mailing List acknowledging that. [Move the following to a section on the form] If a record represents a new subtag that does not currently exist in the registry, then the message's subject line MUST include the word "INSERT". If the record represents a change to an existing subtag, then the subject line of the message MUST include the word "MODIFY". The message MUST contain both the record for the subtag being inserted or modified and the new File-Date record. Here is an example of what the body of the message might contain: 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 Section 3.6 (Possibilities for Registration ) for more information. The decision making process about which tags were initially grandfathered and which were made redundant is described in [initial-registry] ( Ewell, D., Ed., "Initial Language Subtag Registry," June 2005.). Whenever an entry is created or modified in the registry, the 'File-Date' record at the start of the registry is updated to reflect the most recent modification date in the [RFC3339] (Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps," July 2002. ) "full-date" format. Before forwarding a new registration to IANA, the Language Subtag Reviewer MUST ensure that values in the 'Subtag' field match case according to the description in Section 3.1 (Format of the IANA Language Subtag Registry ). ------=_NextPart_000_00E5_01C6E0D8.15287AD0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Mark=20 wrote wrt:
 
>=20 We clearly need = some more=20 process in the spec -- I didn't realize, for example, that the armenian = tags=20 were added.
I am=20 not sure that I saw the registration forms being submitted for inclusion = into=20 the Registry...
 
> 3.2. Language Subtag = Review=20 Board
 
In=20 essence, I very much like it, although I have not yet looked at the = detailed=20 wording.  However, I would propose the following change=20 from:
 
----

> Any instance where the LSB does not follow the = procedures=20 in this

> document are grounds for dismissal by the = IESG.

-----

To

-----

Any=20 instance where the LSB does not follow the procedures in this document = MAY be=20 considered as grounds for dismissal by the IESG.

----

I=20 think we need to allow for human error.  A simple human error which = can be=20 corrected should not be grounds for dismissal unless it is truly = considered to=20 be negligence on the part of the LSRB.
 
In=20 response to Doug where he wrote:
 

> I would = like to see=20 some provision for limited extension of these 30-day and 15-day limits, = in case=20 one or more of the Reviewers is absent or unavailable,

> = preventing the=20 two-thirds majority vote. I can easily imagine a problem arising if a = request is=20 filed in early to mid-December.

One=20 Reviewer can be unavailable. You would still have a majority vote; = thus=20 only two Reviewers are ever required to action = changes. However, there=20 could be a situation where two (or even 3) Reviewers were unavailable = (unlikely=20 I know) but maybe some wording to say that the LSRB can advise the list = of a=20 time extension where deemed necessary. Necessary can be defined as being = where=20 two or more Reviewers are absent.

On=20 another note, to protect the Registry from requests that may be made by = people=20 with "ulterior motives" I also think it might be appropriate to state = that =20 x number (for instance 5) of people need to show support for additions = to the=20 Registry that do not form part of the underlying ISO/UN standards.  = But I=20 am not completely hung up on this; although it could also encourage = people to=20 comment more often which can only be good.

Best=20 regards

 

Debbie=20 Garside


From: Mark Davis=20 [mailto:mark.davis@icu-project.org]
Sent: 25 September 2006 = 16:50
To: LTRU Working Group
Subject: [Ltru]=20 Process

We clearly need some more process in the spec -- I didn't = realize,=20 for example, that the armenian tags were added.

Here is a very = rough=20 draft revision of 3.2/3.3, incorporating some ideas that we've = discussed at=20 various times.

3.2. Language Subtag Review Board

The Language Subtag Board (LSB) consists of three Language Subtag=20 Reviewers. Each of the Language Subtag Reviewers.must read and = thoroughly=20 understand all parts of BCP 47. All decisions of the LSB are by a = majority=20 vote. The Language Subtag Board is appointed by the IESG for an = indefinite=20 term, subject to removal or replacement at the IESG's discretion. Any = instance=20 where the LSB does not follow the procedures in this document are = grounds for=20 dismissal by the IESG.

The Language Subtag Board moderates the ietf-languages mailing = list,=20 responds to requests for registration, and performs the other registry = maintenance duties described in Section 3.3=20 (Maintenance of the Registry=20 ). Only the Language Subtag Board is permitted to = request=20 IANA to change, update or add records to the Language Subtag = Registry.

The performance or decisions of the Language Subtag Board MAY be = appealed=20 to the IESG under the same rules as other IETF decisions (see [RFC2026]=20 (Bradner, S., "The Internet Standards = Process --=20 Revision 3," October 1996. )). The IESG = can=20 reverse or overturn the decision of the Language Subtag Board, provide = guidance, or take other appropriate actions. Because of the need for=20 stability, however, once a change is posted to http://= www.iana.org/assignments/language-subtag-registry,=20 it is irrevocable.

3.3. Maintenance of the Registry

Maintenance of the registry requires that as codes are assigned or=20 withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language = Subtag=20 Board MUST evaluate each change, determine whether it conflicts with = existing=20 registry entries, and within 30 days propose a change to the registry = as=20 described in Section 3.5.

The Language Subtag Board MUST ensure that all new subtags meet the = requirements in Section 4.1=20 (Choice of Language = Tag) or=20 submit an appropriate alternate subtag as described in that section. = The=20 Language Subtag Board MUST respond within 15 days to any language = subtag=20 request form. The response MUST go both to the submitter, and to the = Language=20 Tag Registry Mailing List. The response MUST indicate whether the = request is=20 accepted, or not accepted. If it is not accepted, the Language Subtag = Board=20 MUST indicate which clauses of BCP 47 would be violated by acceptance, = and=20 which changes to the language subtag request form would make it = acceptable.=20

Upon acceptance, the Language Subtag Board MUST incorporate = corresponding=20 changes into a public Draft Language Tag Registry, having precisely = the same=20 syntax as http://= www.iana.org/assignments/language-subtag-registry,=20 and notify the Language Tag Registry Mailing List. During a 15-day = review=20 period, people have the opportunity to review the syntax of the = change, and=20 the Language Subtag Board may make changes in response to feedback. = Any such=20 change starts the 15-day review period anew. Once the review period = has=20 completed, the LSB will change the File-Date and forward the entire = file to=20 IANA for posting within 7 days. Once IANA has posted the file, IANA = MUST send=20 a message will be sent to the Language Tag Registry Mailing List = acknowledging=20 that.


[Move the following to a section on the form]

If a record represents a new subtag that does not currently exist = in the=20 registry, then the message's subject line MUST include the word = "INSERT". If=20 the record represents a change to an existing subtag, then the subject = line of=20 the message MUST include the word "MODIFY". The message MUST contain = both the=20 record for the subtag being inserted or modified and the new File-Date = record.=20 Here is an example of what the body of the message might = contain:

The set of redundant and grandfathered tags is permanent and = stable: new=20 entries in this section MUST NOT be added and existing entries MUST = NOT be=20 removed. Records of type 'grandfathered' MAY have their type converted = to=20 'redundant': see item 12 in Section 3.6=20 (Possibilities for Registration=20 ) for more information. The decision making process = about=20 which tags were initially grandfathered and which were made redundant = is=20 described in [initial-registry]=20 ( Ewell, D., Ed., "Initial Language Subtag = Registry,"=20 June 2005.).

Whenever an entry is created or modified in the registry, the = 'File-Date'=20 record at the start of the registry is updated to reflect the most = recent=20 modification date in the [RFC3339]=20 (Klyne, G. and C. Newman, "Date and Time on = the=20 Internet: Timestamps," July 2002. ) = "full-date"=20 format.

Before forwarding a new registration to IANA, the Language Subtag = Reviewer=20 MUST ensure that values in the 'Subtag' field match case according to = the=20 description in Section 3.1=20 (Format of the IANA Language Subtag = Registry=20 ).

------=_NextPart_000_00E5_01C6E0D8.15287AD0-- --===============1175660606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1175660606==-- From ltru-bounces@ietf.org Mon Sep 25 14:38:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRvLh-0007Ed-Mp; Mon, 25 Sep 2006 14:38:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRvLg-0007EQ-W4 for ltru@ietf.org; Mon, 25 Sep 2006 14:38:36 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRvLc-0004Yl-PO for ltru@ietf.org; Mon, 25 Sep 2006 14:38:36 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GRvLc-00016u-Eu; Mon, 25 Sep 2006 14:38:32 -0400 Date: Mon, 25 Sep 2006 14:38:32 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Process Message-ID: <20060925183832.GF14913@ccil.org> References: <016201c6e0c9$b7d7cf60$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <016201c6e0c9$b7d7cf60$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > >The IESG can reverse or overturn the decision of the Language Subtag > >Board, provide guidance, or take other appropriate actions. > > I don't understand the difference between reversing a decision and > overturning it. This wording is also in RFC 4646. I understand the technical distinction to be that when a decision is overruled, a contrary decision is put in its place; whereas when a decision is reversed, no decision is put in place and the question becomes once again undecided. -- You are a child of the universe no less John Cowan than the trees and all other acyclic http://www.ccil.org/~cowan graphs; you have a right to be here. cowan@ccil.org --DeXiderata by Sean McGrath _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 25 16:10:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRwmV-0004RZ-Um; Mon, 25 Sep 2006 16:10:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRwmU-0004RP-IN for ltru@ietf.org; Mon, 25 Sep 2006 16:10:22 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRwmT-0005wD-8o for ltru@ietf.org; Mon, 25 Sep 2006 16:10:22 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060925201020.FBWB22169.mta11.adelphia.net@DGBP7M81>; Mon, 25 Sep 2006 16:10:20 -0400 Message-ID: <018a01c6e0de$a14a4b00$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "'LTRU Working Group'" References: <3B4E8BD05FDB439B9EA0BAD65D25B19C.MAI@home> Subject: Re: [Ltru] Process Date: Mon, 25 Sep 2006 13:10:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: >> We clearly need some more process in the spec -- I didn't realize, >> for example, that the armenian tags were added. > > I am not sure that I saw the registration forms being submitted for > inclusion into the Registry... I agree that there was a process lapse here, although I contend it was a minor one. I'm partially responsible for this. On September 16 I sent a mail to ietf-languages noting that the 2-week review period had passed for all four tags and that no serious objections remained, and recommending that they be approved. Michael, who was preparing for a meeting halfway around the world, asked me to send him the request forms so he could forward them to IANA, which I did. I can't "approve" the requests so I didn't send an announcement to that effect, and IANA didn't send announcements to the list that they had updated the Registry (though I did receive them through Michael). Remember that the main objections to all four of these subtags had originally come from Michael, who ended up approving them. > However, I would propose the following change from: > > ---- >> Any instance where the LSB does not follow the procedures in this >> document are grounds for dismissal by the IESG. > ----- > To > ----- > Any instance where the LSB does not follow the procedures in this > document MAY be considered as grounds for dismissal by the IESG. > ---- > I think we need to allow for human error. A simple human error which > can be corrected should not be grounds for dismissal unless it is > truly considered to be negligence on the part of the LSRB. I agree. > One Reviewer can be unavailable. You would still have a majority vote; > thus only two Reviewers are ever required to action changes. However, > there could be a situation where two (or even 3) Reviewers were > unavailable (unlikely I know) but maybe some wording to say that the > LSRB can advise the list of a time extension where deemed necessary. > Necessary can be defined as being where two or more Reviewers are > absent. I would also like to see whatever Reviewers we end up with -- one, three, or whatever -- drop a note to the list whenever they will be unavailable for more than a few days. Everyone understands the notion of conflicting commitments, but we need to know when delays and silence can be expected. I don't propose writing this into the RFC since it would be almost impossible to enforce; I just think it's a good idea. > On another note, to protect the Registry from requests that may be > made by people with "ulterior motives" I also think it might be > appropriate to state that x number (for instance 5) of people need to > show support for additions to the Registry that do not form part of > the underlying ISO/UN standards. But I am not completely hung up on > this; although it could also encourage people to comment more often > which can only be good. I'm not sure how well that would work. I know the IETF tries to steer toward "rough consensus" and stay away from "voting." Additionally, 5 or any number we could come up with would be arbitrary. But I certainly agree with the principle: if only 1 or 2 ietf-languages list members out of 135 speak up, in favor of a proposal or against it, how much do we really know? -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 25 17:39:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRyAb-0006jQ-5K; Mon, 25 Sep 2006 17:39:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRyAa-0006jK-2i for ltru@ietf.org; Mon, 25 Sep 2006 17:39:20 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRyAY-0000fj-Ke for ltru@ietf.org; Mon, 25 Sep 2006 17:39:20 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004778877.msg for ; Mon, 25 Sep 2006 22:40:36 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Mon, 25 Sep 2006 22:38:54 +0100 From: "Debbie Garside" To: , "'LTRU Working Group'" Subject: RE: [Ltru] Process Date: Mon, 25 Sep 2006 22:38:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: Acbg3vjovyQbmvv1TrivJttzdFkoUgABciFA In-Reply-To: <018a01c6e0de$a14a4b00$6401a8c0@DGBP7M81> Message-ID: <684116B9D2EF419FAF35A2ACEC537352.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Mon, 25 Sep 2006 22:40:36 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Mon, 25 Sep 2006 22:40:36 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug wrote: > > I am not sure that I saw the registration forms being submitted for > > inclusion into the Registry... > > I agree that there was a process lapse here, although I > contend it was a minor one. I'm partially responsible for > this. On September 16 I sent a mail to ietf-languages noting > that the 2-week review period had passed for all four tags > and that no serious objections remained, and recommending > that they be approved. Michael, who was preparing for a > meeting halfway around the world, asked me to send him the > request forms so he could forward them to IANA, which I did. > I can't "approve" the requests so I didn't send an > announcement to that effect, and IANA didn't send > announcements to the list that they had updated the Registry > (though I did receive them through Michael). > > Remember that the main objections to all four of these > subtags had originally come from Michael, who ended up approving them. I don't think there is any dispute that they should be registered it is just that the list were not informed as would normally (I thought) be the case. I think this highlights a need for refining the process as proposed by Mark. I think the current Reviewer and his able assistant have done a fantastic job in the past :-) > > One Reviewer can be unavailable. You would still have a > majority vote; > > thus only two Reviewers are ever required to action > changes. However, > > there could be a situation where two (or even 3) Reviewers were > > unavailable (unlikely I know) but maybe some wording to say > that the > > LSRB can advise the list of a time extension where deemed necessary. > > Necessary can be defined as being where two or more Reviewers are > > absent. > > I would also like to see whatever Reviewers we end up with -- > one, three, or whatever -- drop a note to the list whenever > they will be unavailable for more than a few days. Everyone > understands the notion of conflicting commitments, but we > need to know when delays and silence can be expected. I > don't propose writing this into the RFC since it would be > almost impossible to enforce; I just think it's a good idea. I agree. But I think it could quite easily be written in. Proposed text: --- LSRB members to inform IETF-languages of any times when they expect to be unavailable to perform their functions in this role for a period of more than 3 days. --- Or some such... Am sure somebody can come up with something better... It's been a long day with a lot of documents. > I'm not sure how well that would work. I know the IETF tries > to steer toward "rough consensus" and stay away from > "voting." Additionally, 5 or any number we could come up > with would be arbitrary. But I certainly agree with the > principle: if only 1 or 2 ietf-languages list members out of > 135 speak up, in favor of a proposal or against it, how much > do we really know? I think what I would really like to see is list subscribers joining in. You quote 135. Is that the actual number subscribed? If so, I would estimate only 15-20% ever comment. I would like to see more encouragement for list subscribers to participate... I would see it as part of the LSRB's duties to encourage more participation and to inform list members/subscribers. I would also like to see those who are responsible for the lists Chairs/Reviewers etc including links in their email footers to the current documents that are relevant to the working group. Somebody joining the list today will not have a clue what we are talking about or where to find the documents. Part of standardisation work is about getting the message out there. We can create standards to our hearts content but if people don't know where to find them they are useless. Best Debbie > > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > RFC 4645 * UTN #14 > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 25 21:02:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS1L1-0001BF-I7; Mon, 25 Sep 2006 21:02:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS1Kz-00019O-P7 for ltru@ietf.org; Mon, 25 Sep 2006 21:02:17 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS1Kv-0007fT-TI for ltru@ietf.org; Mon, 25 Sep 2006 21:02:17 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8Q122ff004952 for ; Tue, 26 Sep 2006 10:02:02 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5ed9_9e710274_4cfa_11db_8359_0014221f2a2d; Tue, 26 Sep 2006 10:02:01 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35005) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 26 Sep 2006 10:02:00 +0900 Message-Id: <6.0.0.20.2.20060925161004.08344880@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 25 Sep 2006 16:28:34 +0900 To: "Mark Davis" , "Stephen Deach" From: Martin Duerst In-Reply-To: <30b660a20609241314g2c885883g1c90b8ccb72ebcec@mail.gmail.co m> References: <6.0.0.20.2.20060923112831.023f4d80@localhost> <6.1.1.1.2.20060923074520.02246bb0@namailhost.corp.adobe.com> <30b660a20609230931y3c7ed6bah38549885e72b1aa8@mail.gmail.com> <6.0.0.20.2.20060924113309.02411740@localhost> <6.1.1.1.2.20060924074344.0212c5a0@namailhost.corp.adobe.com> <30b660a20609241314g2c885883g1c90b8ccb72ebcec@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Misha Wolf , ltru@ietf.org Subject: [Ltru] Advice for software; basic well-formedness (was: Updated article: Two-letter or three-letter language codes) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [I have removed www-international@w3.org because this gets more LTRU-specific] At 05:14 06/09/25, Mark Davis wrote: >3. Guidance for User Agents. This raises a point we should probably have language in 4646bis for. Here's rough text for it; I anticipate that this will generate some discussion ;-) > >When a user agent, such as a browser, allows users to enter a language tag by typing, the results SHOULD be checked for well-formedness. If the user agent is not regularly updated to the latest registry, it SHOULD NOT require validity, because that could exclude current, valid language tags. It is recommended, however, that the user be notified that the language tag may not be valid. I think we already have started discussing this, and I think some more guidance in this direction may be appropriate, but I hope we can word it more generally, not so browser-specific. Thinking out lound, in practical terms, what I would do would be: - Check for well-formedness. If not well-formed, alert the user about as follows: "$@*&%" cannot be a language tag. Please change. - Check for validity against a built-in list. If not valid against that list, ask the user, about as follows: I have a large list of tags and subtags (about 7000), but your subtag "foo" isn't in that list. For a complete, up-to-date list, please check IANA (address here). After this, the two alternatives [go ahead anyway] [change] The reason for why the second one makes sense is that for 99.99% and more of actual uses, even if some software doesn't have the latest version, tags can be validated. So if the software can't validate a tag, the chance there is a mistake is much higher than the chance that there was an update recently. This is also true for the current (RFC 4646, iso-639-1/2 only) state, because in terms of occurrence, these subtags are way more frequent than iso-639-3. In some sense, it's actually more true for iso-639-1/2 only: iso-639-3 populates the 3-letter code space rather densly (40%). At that density, the chance of a typo hitting another valid code and being accepted is getting higher. >4. Basic Well-Formedness. We may also want to have the notion of basic well-formedness, which that part of validity which can be checked with a regular expression. The difference is that basic well-formedness doesn't check for multiple singleton extensions. The value of doing this is that (a) it covers 99.999...% of the value of a well-formedness check, and (b) it is a much easier sell to implementers that all they need is a simple regex check. Shouldn't you say "that part of well-formedness" rather than "that part of validity" above? Also, I think that having three levels is a bit much. The difference is not so big, the implementation effort also not too different (well, it depends a lot on the language used), and implementors are known to cut corners when they can anyway, with or without permission in the spec. One choice would be to loosen well-formedness a bit, but I'm not convinced yet that that's the way to go. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 25 21:17:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS1Za-0008Kr-OS; Mon, 25 Sep 2006 21:17:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS1ZZ-0008Gz-Vy for ltru@ietf.org; Mon, 25 Sep 2006 21:17:21 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS1ZY-0000uE-Ll for ltru@ietf.org; Mon, 25 Sep 2006 21:17:21 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060926011711.RXCD5459.mta9.adelphia.net@DGBP7M81>; Mon, 25 Sep 2006 21:17:11 -0400 Message-ID: <001101c6e109$7e9b73b0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "'LTRU Working Group'" References: <684116B9D2EF419FAF35A2ACEC537352.MAI@home> Subject: Re: [Ltru] Process Date: Mon, 25 Sep 2006 18:17:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: >> Remember that the main objections to all four of these subtags had >> originally come from Michael, who ended up approving them. > > I don't think there is any dispute that they should be registered it > is just that the list were not informed as would normally (I thought) > be the case. It would normally be the case. I think 90% of it was that Michael was headed to Tokyo at the time. > I think this highlights a need for refining the process as proposed by > Mark. +1 >> I would also like to see whatever Reviewers we end up with -- one, >> three, or whatever -- drop a note to the list whenever they will be >> unavailable for more than a few days. > > I agree. But I think it could quite easily be written in. > > Proposed text: > LSRB members to inform IETF-languages of any times when they expect to > be unavailable to perform their functions in this role for a period of > more than 3 days. I don't disagree that it could be written in easily. I just don't know how it would handled as a requirement. Clearly it's not proof of severe dereliction of duty. > I think what I would really like to see is list subscribers joining > in. You quote 135. Is that the actual number subscribed? The list of subscribers is freely available, and it shows 115 non-digest members and 19 digest members. Either I rounded it, or I can't count. The actual number is a bit less since some people are subscribed under two or more addresses. (I'm one of them; the one "private member" is my work address.) > If so, I would estimate only 15-20% ever comment. I would like to see > more encouragement for list subscribers to participate... So would I, but... > I would see it as part of the LSRB's duties to encourage more > participation and to inform list members/subscribers. I agree with the intent, and I do my best as I'm sure others do, but again I'm not seeing how someone could be held to that. What guidelines could be used to determine how good a job someone is doing at getting the word out? > I would also like to see those who are responsible for the lists > Chairs/Reviewers etc including links in their email footers to the > current documents that are relevant to the working group. Somebody > joining the list today will not have a clue what we are talking about > or where to find the documents. Part of standardisation work is about > getting the message out there. We can create standards to our hearts > content but if people don't know where to find them they are useless. Bob's your uncle: -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 25 22:28:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS2gD-00086V-6D; Mon, 25 Sep 2006 22:28:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS2gC-00086Q-Dk for ltru@ietf.org; Mon, 25 Sep 2006 22:28:16 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS2g6-0004Ko-MM for ltru@ietf.org; Mon, 25 Sep 2006 22:28:16 -0400 Received: from [10.72.76.23] (snvvpn2-10-72-76-c23.corp.yahoo.com [10.72.76.23]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8Q2RlLg045444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Sep 2006 19:27:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=v9NaVpq/PesWIuiL0T4gOba5SCp0VqHcZj/2Fd1ZIwTRmZVMRlCpn0xBBK3n0qSB Message-ID: <45189023.4000300@yahoo-inc.com> Date: Mon, 25 Sep 2006 19:27:47 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Process References: <30b660a20609250849k455115ci4ca24ebfcb175c2c@mail.gmail.com> In-Reply-To: <30b660a20609250849k455115ci4ca24ebfcb175c2c@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I've spent some time today thinking about this. My thoughts: I'm not sure that changing the format of the reviewer job from an individual to a group would necessarily improve the process. I think the problem with the reviewer job as presently constituted is that it allows for arbitrary and binding decisions by an individual and that it provides a lack of clarity during the process. I think the process would best be improved if: 1. Requests were posted to a Web site, along with their current status and expiry dates for the current review period and/or process state. The most recent approved/rejected items should be visible as well as items in progress. I-D tracker is a good model here. 2. Requests should be considered as constituted. Consensus decisions should be made about a specific record as requested. Changes to the requested record should restart the consideration period. This allows for a more reasoned discussion with clear date points. 3. Approved items should have a grace period before being forwarded to IANA. This allows any disagreements with the reviewer's decision to be decided on the list or appealed to the IESG. Infinite delaying tactics must be prevented. So should "pocket vetoes" on the part of the reviewer. But it should be entirely clear when something is approved and a few days delay in case of a "bad decision" will not hurt anything. 4. Rejections must take the form of either rule violations of BCP 47 (preventing the registration) or must be decisions about list consensus by the reviewer. I think the reviewer's opinion should not count for more than everyone else on the list's opinion. By reducing the reviewer to "chair of the list", we also reduce appeal inducing decisions to those normal to the IETF, that is: that the consensus of the list was flawed. I think this last is important. When Mark and I started this adventure, Mark also registered some stopgap tags. These did reach list consensus--except for the reviewer, who had to be threatened with appeal (at that time unprecedented in list history) to get him to forward the registrations. Removing the arbitrary judgment element from the reviewer's job does not remove the reviewer's "bully pulpit", but it does make this process more reasoned. So I find that I'm not ready quite yet to support Mark's edits as they sit, although I'm *highly* sympathetic to them, having observed the general dysfunctionality of ietf-languages of late. It should be easy, clear, and entirely straightforward to get a registration... and rejections should also be clear. If something remedial can be done to them, then the registrant should be clear on what that is. I think we can achieve that best *not* creating a review board, but rather by pulling the sometimes-arcane rules together more tightly and improving the transparency of the process. Best Regards, Addison Mark Davis wrote: > We clearly need some more process in the spec -- I didn't realize, for > example, that the armenian tags were added. > > Here is a very rough draft revision of 3.2/3.3, incorporating some ideas > that we've discussed at various times. > > 3.2. Language Subtag Review Board > > The Language Subtag Board (LSB) consists of three Language Subtag > Reviewers. > Each of the Language Subtag Reviewers.must read and thoroughly understand > all parts of BCP 47. All decisions of the LSB are by a majority vote. The > Language Subtag Board is appointed by the IESG for an indefinite term, > subject to removal or replacement at the IESG's discretion. Any instance > where the LSB does not follow the procedures in this document are grounds > for dismissal by the IESG. > > The Language Subtag Board moderates the ietf-languages mailing list, > responds to requests for registration, and performs the other registry > maintenance duties described in Section 3.3 (Maintenance of the > Registry). > > Only the Language Subtag Board is permitted to request IANA to change, > update or add records to the Language Subtag Registry. > > The performance or decisions of the Language Subtag Board MAY be > appealed to > the IESG under the same rules as other IETF decisions (see [RFC2026] > (Bradner, > S., "The Internet Standards Process -- Revision 3," October > 1996.)). > > The IESG can reverse or overturn the decision of the Language Subtag Board, > provide guidance, or take other appropriate actions. Because of the need > for > stability, however, once a change is posted to > http://www.iana.org/assignments/language-subtag-registry, it is > irrevocable. > 3.3. Maintenance of the Registry > > Maintenance of the registry requires that as codes are assigned or > withdrawn > by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language Subtag Board > MUST > evaluate each change, determine whether it conflicts with existing registry > entries, and within 30 days propose a change to the registry as > described in > Section 3.5. > > The Language Subtag Board MUST ensure that all new subtags meet the > requirements in Section 4.1 (Choice of Language > Tag)or > > submit an appropriate alternate subtag as described in that section. > The > Language Subtag Board MUST respond within 15 days to any language subtag > request form. The response MUST go both to the submitter, and to the > Language Tag Registry Mailing List. The response MUST indicate whether the > request is accepted, or not accepted. If it is not accepted, the Language > Subtag Board MUST indicate which clauses of BCP 47 would be violated by > acceptance, and which changes to the language subtag request form would > make > it acceptable. > > Upon acceptance, the Language Subtag Board MUST incorporate corresponding > changes into a public Draft Language Tag Registry, having precisely the > same > syntax as http://www.iana.org/assignments/language-subtag-registry, and > notify the Language Tag Registry Mailing List. During a 15-day review > period, people have the opportunity to review the syntax of the change, and > the Language Subtag Board may make changes in response to feedback. Any > such > change starts the 15-day review period anew. Once the review period has > completed, the LSB will change the File-Date and forward the entire file to > IANA for posting within 7 days. Once IANA has posted the file, IANA MUST > send a message will be sent to the Language Tag Registry Mailing List > acknowledging that. > > [Move the following to a section on the form] > > If a record represents a new subtag that does not currently exist in the > registry, then the message's subject line MUST include the word > "INSERT". If > the record represents a change to an existing subtag, then the subject line > of the message MUST include the word "MODIFY". The message MUST contain > both > the record for the subtag being inserted or modified and the new File-Date > record. Here is an example of what the body of the message might contain: > > 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 Section 3.6 (Possibilities for > Registration)for > > more information. The decision making process about which tags were > initially grandfathered and which were made redundant is described in > [initial-registry] (Ewell, D., Ed., "Initial Language Subtag Registry," > June > 2005.) > > . > > Whenever an entry is created or modified in the registry, the 'File-Date' > record at the start of the registry is updated to reflect the most recent > modification date in the [RFC3339] (Klyne, G. and C. Newman, "Date and Time > on the Internet: Timestamps," July > 2002.)"full-date" > > format. > > Before forwarding a new registration to IANA, the Language Subtag Reviewer > MUST ensure that values in the 'Subtag' field match case according to the > description in Section 3.1 (Format of the IANA Language Subtag > Registry). > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 26 03:04:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS6zS-0008Od-Ju; Tue, 26 Sep 2006 03:04:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS6zR-0008OY-5v for ltru@ietf.org; Tue, 26 Sep 2006 03:04:25 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS6zP-00015s-TB for ltru@ietf.org; Tue, 26 Sep 2006 03:04:25 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 39C3426C209; Tue, 26 Sep 2006 09:04:13 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 952FA26C1CB; Tue, 26 Sep 2006 09:04:07 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 91EE658ED14; Tue, 26 Sep 2006 09:04:07 +0200 (CEST) Date: Tue, 26 Sep 2006 09:04:07 +0200 From: Stephane Bortzmeyer To: Martin Duerst Message-ID: <20060926070407.GA31084@nic.fr> References: <6.0.0.20.2.20060923112831.023f4d80@localhost> <6.1.1.1.2.20060923074520.02246bb0@namailhost.corp.adobe.com> <30b660a20609230931y3c7ed6bah38549885e72b1aa8@mail.gmail.com> <6.0.0.20.2.20060924113309.02411740@localhost> <6.1.1.1.2.20060924074344.0212c5a0@namailhost.corp.adobe.com> <30b660a20609241314g2c885883g1c90b8ccb72ebcec@mail.gmail.com> <6.0.0.20.2.20060925161004.08344880@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060925161004.08344880@localhost> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org Subject: [Ltru] Re: Advice for software; basic well-formedness (was: Updated article: Two-letter or three-letter language codes) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Mon, Sep 25, 2006 at 04:28:34PM +0900, Martin Duerst wrote a message of 60 lines which said: > - Check for validity against a built-in list. [...] iso-639-3 > populates the 3-letter code space rather densly (40%). At that > density, the chance of a typo hitting another valid code and being > accepted is getting higher. A good thing about validity testing is that you can display the full description, not only the 3-letter code. How about using the built-in list to display in an human-friendly way the semantics of the tag, before asking confirmation? % ./display-tag man-Nkoo-GN man-Nkoo-GN: (man: language "Mandingo", Nkoo: script "N’Ko", GN: region "Guinea") _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 26 04:00:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS7rR-0003oW-JU; Tue, 26 Sep 2006 04:00:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS7rQ-0003nD-Jl for ltru@ietf.org; Tue, 26 Sep 2006 04:00:12 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS7rP-0006pn-8r for ltru@ietf.org; Tue, 26 Sep 2006 04:00:12 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004781279.msg for ; Tue, 26 Sep 2006 09:01:15 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Tue, 26 Sep 2006 08:59:33 +0100 From: "Debbie Garside" To: Date: Tue, 26 Sep 2006 08:59:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcbhMQkp6TrB42sRSRGBFwxZqiffPgAECKRg In-Reply-To: <003501c6e130$bf003720$6401a8c0@DGBP7M81> Message-ID: <16895F1EF5FE49009333587955F0449D.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Tue, 26 Sep 2006 09:01:15 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Tue, 26 Sep 2006 09:01:16 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: dewell@adelphia.net, 'LTRU Working Group' Subject: [Ltru] RE: LANGUAGE SUBTAG REGISTRATION FORM: Variant for a Latin-basedalphabet for Id?l-Ural (Qazan) Tatar (iqtel) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug wrote: > We still have not resolved the question of how to tag > transliterations and transcriptions. I pray we come up with > a real system, not just an ad-hoc solution for this one case. I really think we need a discussion wrt ISO 639-6. I have cross copied this to the LTRU list. Best regards Debbie > -----Original Message----- > From: ietf-languages-bounces@alvestrand.no > [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of Doug Ewell > Sent: 26 September 2006 06:58 > To: ietf-languages@iana.org > Subject: Re: LANGUAGE SUBTAG REGISTRATION FORM: Variant for a > Latin-basedalphabet for Id?l-Ural (Qazan) Tatar (iqtel) > > Reshat Sabiq wrote: > > > 7. Recommended prefix(es) of subtag (for variants): > > tt, tat > > Note that the only valid primary language subtag for Tatar is > "tt", derived from the ISO 639-1 code element. "tat", the > ISO 639-2 code element, is not valid. > > We still have not resolved the question of how to tag > transliterations and transcriptions. I pray we come up with > a real system, not just an ad-hoc solution for this one case. > > -- > 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 > > _______________________________________________ > Ietf-languages mailing list > Ietf-languages@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 26 06:14:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS9xY-0004Le-LL; Tue, 26 Sep 2006 06:14:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS9xX-0004LY-Cj for ltru@ietf.org; Tue, 26 Sep 2006 06:14:39 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS9xV-0005m9-1S for ltru@ietf.org; Tue, 26 Sep 2006 06:14:39 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004783282.msg for ; Tue, 26 Sep 2006 11:16:15 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Tue, 26 Sep 2006 11:14:31 +0100 From: "Debbie Garside" To: , "'LTRU Working Group'" Subject: RE: [Ltru] Process Date: Tue, 26 Sep 2006 11:14:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcbhCda4XAY6B7OPT+u4b3IOWmzrDAASTaFg In-Reply-To: <001101c6e109$7e9b73b0$6401a8c0@DGBP7M81> Message-ID: X-Spam-Processed: mx1.nexbyte.net, Tue, 26 Sep 2006 11:16:15 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Tue, 26 Sep 2006 11:16:16 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug wrote: > > I would see it as part of the LSRB's duties to encourage more > > participation and to inform list members/subscribers. > > I agree with the intent, and I do my best as I'm sure others > do, but again I'm not seeing how someone could be held to > that. What guidelines could be used to determine how good a > job someone is doing at getting the word out? I don't think we necessarily need to write it into the document, or, indeed, hold anyone to account, but I think (from memory) on the occasions when Chairs/Editors have specifically called for comments it has produced a better response; even if the response is (just) a +/-1. This should be standard practice or, at the very least, encouraged as good practice for list/WG management. > > I would also like to see those who are responsible for the lists > > Chairs/Reviewers etc including links in their email footers to the > > current documents that are relevant to the working group. Somebody > > joining the list today will not have a clue what we are > talking about > > or where to find the documents. Part of standardisation > work is about > > getting the message out there. We can create standards to > our hearts > > content but if people don't know where to find them they > are useless. > > Bob's your uncle: Thank you :-) Debbie > > -- > 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 26 06:17:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSA0V-0005RS-7E; Tue, 26 Sep 2006 06:17:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSA0T-0005Pe-6q for ltru@ietf.org; Tue, 26 Sep 2006 06:17:41 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSA0P-0006GA-5w for ltru@ietf.org; Tue, 26 Sep 2006 06:17:41 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8QAHXGX012791 for ; Tue, 26 Sep 2006 19:17:33 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 1c36_3993548a_4d48_11db_8605_0014221fa3c9; Tue, 26 Sep 2006 19:17:32 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:50737) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 26 Sep 2006 19:17:31 +0900 Message-Id: <6.0.0.20.2.20060926164259.07421900@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 26 Sep 2006 19:17:18 +0900 To: "Mark Davis" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Process In-Reply-To: <30b660a20609250849k455115ci4ca24ebfcb175c2c@mail.gmail.com > References: <30b660a20609250849k455115ci4ca24ebfcb175c2c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [partially as a co-chair, and partially as a technical contributor] The IETF has a tradition to keep process as low-key as possible. It would in my understanding be the first time that more than a simple "reviewer" is used for a simple registration. Creating new process is very difficult; it's easy to get it wrong, and it's easy to make it too elaborate. It's then very difficult to make it simpler again. I personally have my doubts that we need that much more process. I'm also a bit concerned that the IESG will ask a lot of questions (at least) when they see things such as "Language Subtag Review Board" or "vote by majority",... While a lot of people participate on ietf-languages@iana.org, and many share an understanding of what's problematic with that list and the review of language tags, the LTRU list is by definition a different list. I think it would be good if somebody (Mark?) could put together a list of the problems he sees. Once we have a better understanding on what we agree are problems, we have a better chance of finding the minimal, but necessary, solutions. Regards, Martin. At 00:49 06/09/26, Mark Davis wrote: >We clearly need some more process in the spec -- I didn't realize, for example, that the armenian tags were added. > >Here is a very rough draft revision of 3.2/3.3, incorporating some ideas that we've discussed at various times. > > > >3.2. Language Subtag Review Board > > >The Language Subtag Board (LSB) consists of three Language Subtag Reviewers. Each of the Language Subtag Reviewers.must read and thoroughly understand all parts of BCP 47. All decisions of the LSB are by a majority vote. The Language Subtag Board is appointed by the IESG for an indefinite term, subject to removal or replacement at the IESG's discretion. Any instance where the LSB does not follow the procedures in this document are grounds for dismissal by the IESG. > >The Language Subtag Board moderates the ietf-languages mailing list, responds to requests for registration, and performs the other registry maintenance duties described in Section 3.3 (Maintenance of the Registry ). Only the Language Subtag Board is permitted to request IANA to change, update or add records to the Language Subtag Registry. > >The performance or decisions of the Language Subtag Board MAY be appealed to the IESG under the same rules as other IETF decisions (see [RFC2026] (Bradner, S., "The Internet Standards Process -- Revision 3," October 1996. )). The IESG can reverse or overturn the decision of the Language Subtag Board, provide guidance, or take other appropriate actions. Because of the need for stability, however, once a change is posted to http://www.iana.org/assignments/language-subtag-registry, it is irrevocable. > > >3.3. Maintenance of the Registry > > > >Maintenance of the registry requires that as codes are assigned or withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language Subtag Board MUST evaluate each change, determine whether it conflicts with existing registry entries, and within 30 days propose a change to the registry as described in Section 3.5. > >The Language Subtag Board MUST ensure that all new subtags meet the requirements in Section 4.1 (Choice of Language Tag) or submit an appropriate alternate subtag as described in that section. The Language Subtag Board MUST respond within 15 days to any language subtag request form. The response MUST go both to the submitter, and to the Language Tag Registry Mailing List. The response MUST indicate whether the request is accepted, or not accepted. If it is not accepted, the Language Subtag Board MUST indicate which clauses of BCP 47 would be violated by acceptance, and which changes to the language subtag request form would make it acceptable. > >Upon acceptance, the Language Subtag Board MUST incorporate corresponding changes into a public Draft Language Tag Registry, having precisely the same syntax as http://www.iana.org/assignments/language-subtag-registry, and notify the Language Tag Registry Mailing List. During a 15-day review period, people have the opportunity to review the syntax of the change, and the Language Subtag Board may make changes in response to feedback. Any such change starts the 15-day review period anew. Once the review period has completed, the LSB will change the File-Date and forward the entire file to IANA for posting within 7 days. Once IANA has posted the file, IANA MUST send a message will be sent to the Language Tag Registry Mailing List acknowledging that. > >[Move the following to a section on the form] > >If a record represents a new subtag that does not currently exist in the registry, then the message's subject line MUST include the word "INSERT". If the record represents a change to an existing subtag, then the subject line of the message MUST include the word "MODIFY". The message MUST contain both the record for the subtag being inserted or modified and the new File-Date record. Here is an example of what the body of the message might contain: > >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 Section 3.6 (Possibilities for Registration ) for more information. The decision making process about which tags were initially grandfathered and which were made redundant is described in [initial-registry] ( Ewell, D., Ed., "Initial Language Subtag Registry," June 2005.). > >Whenever an entry is created or modified in the registry, the 'File-Date' record at the start of the registry is updated to reflect the most recent modification date in the [RFC3339] (Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps," July 2002. ) "full-date" format. > >Before forwarding a new registration to IANA, the Language Subtag Reviewer MUST ensure that values in the 'Subtag' field match case according to the description in Section 3.1 (Format of the IANA Language Subtag Registry ). > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 26 06:17:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSA0i-0005U2-BU; Tue, 26 Sep 2006 06:17:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSA0h-0005Tx-0v for ltru@lists.ietf.org; Tue, 26 Sep 2006 06:17:55 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSA0b-0006GI-MM for ltru@lists.ietf.org; Tue, 26 Sep 2006 06:17:55 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GS9zc-0005vN-AR for ltru@lists.ietf.org; Tue, 26 Sep 2006 12:16:48 +0200 Received: from pd9fbad64.dip0.t-ipconnect.de ([217.251.173.100]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Sep 2006 12:16:48 +0200 Received: from nobody by pd9fbad64.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Sep 2006 12:16:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 26 Sep 2006 12:11:44 +0200 Organization: Lines: 31 Message-ID: <4518FCE0.5A5B@xyzzy.claranet.de> References: <684116B9D2EF419FAF35A2ACEC537352.MAI@home> <001101c6e109$7e9b73b0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad64.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Ltru] Re: Process X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: >> I think this highlights a need for refining the process as >> proposed by Mark. > +1 Let's just allow more time for the decision. It's nobody's business if the reviewer is away for a week or two. If it's for months there should a substitute. > The list of subscribers is freely available That won't tell you much, the one "gmane" subscription should be "private" for technical reasons, and it's a gateway to any number of GMaNe users. Wherever I'm subscribed the first two things I do is "hide subscription" and "switch to write only" (because I read via GMaNe) if possible at all - with mailman it's normally possible. For "public" (GMaNe's POV) lists I normally don't subscribe, the "members only" LTRU was an exception at this time, because I feared that the LTRU Chairs might need fine-grained control. > http://www.alvestrand.no/mailman/listinfo/ietf-languages For Web / news (NNTP) / news (RSS) / search access another URL is http://dir.gmane.org/gmane.ietf.languages Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 26 09:03:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSCac-0000FF-Tr; Tue, 26 Sep 2006 09:03:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSCab-0000FA-Pi for ltru@ietf.org; Tue, 26 Sep 2006 09:03:09 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSCaa-0005VS-Go for ltru@ietf.org; Tue, 26 Sep 2006 09:03:09 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060926130303.NBLY5459.mta9.adelphia.net@DGBP7M81> for ; Tue, 26 Sep 2006 09:03:03 -0400 Message-ID: <00e101c6e16c$1a69d9a0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 26 Sep 2006 06:03:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Ltru] Re: Advice for software; basic well-formedness X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > A good thing about validity testing is that you can display the full > description, not only the 3-letter code. How about using the built-in > list to display in an human-friendly way the semantics of the tag, > before asking confirmation? > > % ./display-tag man-Nkoo-GN > man-Nkoo-GN: (man: language "Mandingo", Nkoo: script "N’Ko", > GN: region "Guinea") Mine displays: Subtag 1: man Language subtag: Mandingo (registered 2005-10-16) Subtag 2: Nkoo Script subtag: N'Ko (registered 2005-10-16) Subtag 3: GN Region subtag: Guinea (registered 2005-10-16) which is admittedly a lot to ask for a broad-purpose application like a browser. -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 26 09:42:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSDCh-0004Ef-7k; Tue, 26 Sep 2006 09:42:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSDCg-0004Ea-Cv for ltru@ietf.org; Tue, 26 Sep 2006 09:42:30 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSDCe-0001re-3v for ltru@ietf.org; Tue, 26 Sep 2006 09:42:30 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060926134227.PSBA5459.mta9.adelphia.net@DGBP7M81>; Tue, 26 Sep 2006 09:42:27 -0400 Message-ID: <010101c6e171$9ba73b20$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 26 Sep 2006 06:42:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ltru] Re: Process X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > While a lot of people participate on ietf-languages at iana.org, and > many share an understanding of what's problematic with that list and > the review of language tags, the LTRU list is by definition a > different list. I think it would be good if somebody (Mark?) could put > together a list of the problems he sees. Once we have a better > understanding on what we agree are problems, we have a better chance > of finding the minimal, but necessary, solutions. Here are a few, in no particular order. Some of these are my opinion, some are not, but I intentionally do not separate them here. 1. Possibility of real or perceived arbitrariness on the part of a single Reviewer. 2. Risk of indeterminate delay when the Reviewer is unavailable, coupled with requirements that things MUST happen within a set period. 3. Unofficial delegation of some of the Reviewer's duties called out in RFC 4646 (list management, administrative function). 4. Inadequate participation on ietf-languages leading to results that are not representative of the community. 5. Lack of feedback to requester and ietf-languages community when a request is accepted or rejected. 6. Need to validate updated Registry against human error before it is publicly posted. -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 26 10:07:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSDay-00086s-50; Tue, 26 Sep 2006 10:07:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSDaw-00085B-DG for ltru@ietf.org; Tue, 26 Sep 2006 10:07:34 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSDMr-0002Wj-5T for ltru@ietf.org; Tue, 26 Sep 2006 09:53:02 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060926135300.USUT22169.mta11.adelphia.net@DGBP7M81>; Tue, 26 Sep 2006 09:53:00 -0400 Message-ID: <010b01c6e173$14eea2b0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 26 Sep 2006 06:53:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Ltru] Re: REQUEST for registration of variant subtag 'grabar' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: > Peter wrote: > >> I trust it is clear to all that I have not opposed the registration >> of a variant subtag for Grabar because I wish to manipulate any list >> against common culture and needed usage, or because I am trying to >> hide my ignorance. Rather, it is because I believe users needing a >> tag for Grabar content will be best served, and the overall coherence >> of our system of ISO 639 IDs and RFC 4646 tags will be optimized, if >> this variety is given an identifier in ISO 639 rather than being >> coded with a variant subtag. > > I think this is perfectly clear and I completely agree. > > I hope other members of this list will also comment on this in order > that we may move forward and respond to the request in the appropriate > manner; with a decision and, assuming others agree, direction to the > ISO 639 JAC. To the extent my opinion on this matters, I thought Peter's intentions were clear and clearly stated, and at no time did I question or second-guess them. -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 26 10:09:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSDcV-0000Yy-MV; Tue, 26 Sep 2006 10:09:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSDcT-0000YD-Qe for ltru@ietf.org; Tue, 26 Sep 2006 10:09:09 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSDcR-0003i9-JY for ltru@ietf.org; Tue, 26 Sep 2006 10:09:09 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GSDcP-0006v2-26; Tue, 26 Sep 2006 10:09:05 -0400 Date: Tue, 26 Sep 2006 10:09:05 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: REQUEST for registration of variant subtag 'grabar' Message-ID: <20060926140904.GN8914@ccil.org> References: <010b01c6e173$14eea2b0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <010b01c6e173$14eea2b0$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > To the extent my opinion on this matters, I thought Peter's intentions > were clear and clearly stated, and at no time did I question or > second-guess them. +1 -- Híggledy-pìggledy / XML programmers John Cowan Try to escape those / I-eighteen-N woes; http://www.ccil.org/~cowan Incontrovertibly / What we need more of is cowan@ccil.org Unicode weenies and / François Yergeaus. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 26 11:20:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSEjs-0005wx-GE; Tue, 26 Sep 2006 11:20:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSEjr-0005wp-7I for ltru@ietf.org; Tue, 26 Sep 2006 11:20:51 -0400 Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSEjl-0007ln-6P for ltru@ietf.org; Tue, 26 Sep 2006 11:20:51 -0400 Received: from eupig2 (unverified [129.1.30.40]) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Tue, 26 Sep 2006 15:20:44 +0000 Received: from lonsmsxb01.emea.ime.reuters.com ([10.14.113.6]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31217) with ESMTP id <0J6700GRXHAJHN@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Tue, 26 Sep 2006 15:20:43 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Tue, 26 Sep 2006 16:20:43 +0100 Date: Tue, 26 Sep 2006 16:19:49 +0100 From: Misha Wolf To: ltru@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: ISO 3166-1 NEWSLETTER No. V-12 ("Serbia" and "Montenegro") Thread-Index: AcbhfzT5s36vC8YLTmGzVn1Z85syAg== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 26 Sep 2006 15:20:44.0005 (UTC) FILETIME=[559C7150:01C6E17F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ltru] ISO 3166-1 NEWSLETTER No. V-12 ("Serbia" and "Montenegro") X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166 /nlv12-div.htm =20 Misha This email was sent to you by Reuters, the global news and information comp= any.=20 To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 26 14:29:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSHg4-0002J5-Kp; Tue, 26 Sep 2006 14:29:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSHg3-0002Iy-3J for ltru@ietf.org; Tue, 26 Sep 2006 14:29:07 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSHg1-0000cx-I5 for ltru@ietf.org; Tue, 26 Sep 2006 14:29:07 -0400 Received: by nf-out-0910.google.com with SMTP id n15so286659nfc for ; Tue, 26 Sep 2006 11:29:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=oSWOMbSSVGVX4KzCP58Di0P41Ht/wd8kIBThvjXQpQunbYI2Iqmloqwkyu3EOvybRhUra/FYxn/yaRtbKcnaAs1AnRQJ+6rQ9aiZl1I3AmHx7F5Asth9Dgzck46t93jbfO9QsMhsXnBRQx8skRZ22JaK5Kur+UNb+tABn+nreWM= Received: by 10.49.8.1 with SMTP id l1mr1392542nfi; Tue, 26 Sep 2006 11:29:02 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Tue, 26 Sep 2006 11:28:52 -0700 (PDT) Message-ID: <30b660a20609261128qc7172c7mdb789f1ed62df404@mail.gmail.com> Date: Tue, 26 Sep 2006 11:28:52 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Advice for software; basic well-formedness In-Reply-To: <00e101c6e16c$1a69d9a0$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <00e101c6e16c$1a69d9a0$6401a8c0@DGBP7M81> X-Google-Sender-Auth: d88e272786b0a200 X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1490049852==" Errors-To: ltru-bounces@ietf.org --===============1490049852== Content-Type: multipart/alternative; boundary="----=_Part_19391_11066822.1159295332075" ------=_Part_19391_11066822.1159295332075 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SnVzdCBmb3IgY29tcGFyaXNvbiwgSUNVIGRpc3BsYXlzICJtYW4tTmtvby1HTiIgbGlrZSB0aGUg Zm9sbG93aW5nLApkZXBlbmRpbmcgb24gdGhlIGxhbmd1YWdlLiBOb3RlIHRoYXQgd2hlcmUgdmV0 dGVycyBoYXZlIG5vdCBzdXBwbGllZCBhCnRyYW5zbGF0aW9uICh0eXBpY2FsbHkgYmVjYXVzZSBp dCBpcyBub3QgYSBwcmlvcml0eSBmb3Igc3BlYWtlcnMgb2YgdGhlCmxhbmdhdWdlKSwgd2UgZGlz cGxheSB0aGUgcGxhaW4gY29kZXMuCgpNYW5kaW5nbyAoTidLbywgR3VpbmVhKQptZW5pbmthIChO a29vLCBHdWluw6llKQpNYW5kaW5nLVNwcmFjaGUgKE5rb28sIEd1aW5lYSkK0LzQsNC90LTQuNC9 0LPQviAoTmtvbywg0JPQstC40L3QtdGPKQptYW4gKE5rb28sINi62YrZhtmK2KcpCi4uLgoKT2Yg Y291cnNlLCBhIFVJIGNvdWxkIGFsbG93IGRpc3BsYXkgaW4gbXVsdGlwbGUgbGFuZ3VhZ2VzLCBh bmQgd2UgbWFrZSBzdXJlCnRoYXQgRW5nbGlzaCBpcyBhbHdheXMgcG9wdWxhdGVkLCBldmVuIGZv ciB0aGUgZGVwcmVjYXRlZCBjb2Rlcy4KCk1hcmsKT24gOS8yNi8wNiwgRG91ZyBFd2VsbCA8ZGV3 ZWxsQGFkZWxwaGlhLm5ldD4gd3JvdGU6Cj4KPiBTdGVwaGFuZSBCb3J0em1leWVyIDxib3J0em1l eWVyIGF0IG5pYyBkb3QgZnI+IHdyb3RlOgo+Cj4gPiBBIGdvb2QgdGhpbmcgYWJvdXQgdmFsaWRp dHkgdGVzdGluZyBpcyB0aGF0IHlvdSBjYW4gZGlzcGxheSB0aGUgZnVsbAo+ID4gZGVzY3JpcHRp b24sIG5vdCBvbmx5IHRoZSAzLWxldHRlciBjb2RlLiBIb3cgYWJvdXQgdXNpbmcgdGhlIGJ1aWx0 LWluCj4gPiBsaXN0IHRvIGRpc3BsYXkgaW4gYW4gaHVtYW4tZnJpZW5kbHkgd2F5IHRoZSBzZW1h bnRpY3Mgb2YgdGhlIHRhZywKPiA+IGJlZm9yZSBhc2tpbmcgY29uZmlybWF0aW9uPwo+ID4KPiA+ ICUgLi9kaXNwbGF5LXRhZyBtYW4tTmtvby1HTgo+ID4gbWFuLU5rb28tR046IChtYW46IGxhbmd1 YWdlICJNYW5kaW5nbyIsIE5rb286IHNjcmlwdCAgIk4mI3gyMDE5O0tvIiwKPiA+IEdOOiByZWdp b24gICJHdWluZWEiKQo+Cj4gTWluZSBkaXNwbGF5czoKPgo+IFN1YnRhZyAxOiBtYW4KPiBMYW5n dWFnZSBzdWJ0YWc6IE1hbmRpbmdvIChyZWdpc3RlcmVkIDIwMDUtMTAtMTYpCj4KPiBTdWJ0YWcg MjogTmtvbwo+IFNjcmlwdCBzdWJ0YWc6IE4nS28gKHJlZ2lzdGVyZWQgMjAwNS0xMC0xNikKPgo+ IFN1YnRhZyAzOiBHTgo+IFJlZ2lvbiBzdWJ0YWc6IEd1aW5lYSAocmVnaXN0ZXJlZCAyMDA1LTEw LTE2KQo+Cj4gd2hpY2ggaXMgYWRtaXR0ZWRseSBhIGxvdCB0byBhc2sgZm9yIGEgYnJvYWQtcHVy cG9zZSBhcHBsaWNhdGlvbiBsaWtlIGEKPiBicm93c2VyLgo+Cj4gLS0KPiBEb3VnIEV3ZWxsICAq ICBGdWxsZXJ0b24sIENhbGlmb3JuaWEsIFVTQSAgKiAgUkZDIDQ2NDUgICogIFVUTiAjMTQKPiBo dHRwOi8vdXNlcnMuYWRlbHBoaWEubmV0L35kZXdlbGwvCj4gaHR0cDovL3d3dzEuaWV0Zi5vcmcv aHRtbC5jaGFydGVycy9sdHJ1LWNoYXJ0ZXIuaHRtbAo+IGh0dHA6Ly93d3cuYWx2ZXN0cmFuZC5u by9tYWlsbWFuL2xpc3RpbmZvL2lldGYtbGFuZ3VhZ2VzCj4KPgo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gTHRydSBtYWlsaW5nIGxpc3QKPiBMdHJ1 QGlldGYub3JnCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQo+ Cg== ------=_Part_19391_11066822.1159295332075 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SnVzdCBmb3IgY29tcGFyaXNvbiwgSUNVIGRpc3BsYXlzICZxdW90O21hbi1Oa29vLUdOJnF1b3Q7 IGxpa2UgdGhlIGZvbGxvd2luZywgZGVwZW5kaW5nIG9uIHRoZSBsYW5ndWFnZS4gTm90ZSB0aGF0 IHdoZXJlIHZldHRlcnMgaGF2ZSBub3Qgc3VwcGxpZWQgYSB0cmFuc2xhdGlvbiAodHlwaWNhbGx5 IGJlY2F1c2UgaXQgaXMgbm90IGEgcHJpb3JpdHkgZm9yIHNwZWFrZXJzIG9mIHRoZSBsYW5nYXVn ZSksIHdlIGRpc3BsYXkgdGhlIHBsYWluIGNvZGVzLgo8YnI+PGJyPk1hbmRpbmdvIChOJ0tvLCBH dWluZWEpPGJyPm1lbmlua2EgKE5rb28sIEd1aW7DqWUpPGJyPk1hbmRpbmctU3ByYWNoZSAoTmtv bywgR3VpbmVhKTxicj7QvNCw0L3QtNC40L3Qs9C+IChOa29vLCDQk9Cy0LjQvdC10Y8pPGJyPm1h biAoTmtvbywg2LrZitmG2YrYpyk8YnI+Li4uPGJyPjxicj5PZiBjb3Vyc2UsIGEgVUkgY291bGQg YWxsb3cgZGlzcGxheSBpbiBtdWx0aXBsZSBsYW5ndWFnZXMsIGFuZCB3ZSBtYWtlCnN1cmUgdGhh dCBFbmdsaXNoIGlzIGFsd2F5cyBwb3B1bGF0ZWQsIGV2ZW4gZm9yIHRoZSBkZXByZWNhdGVkIGNv ZGVzLjxicj48YnI+TWFyazxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gOS8y Ni8wNiwgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPkRvdWcgRXdlbGw8L2I+ICZsdDs8YSBo cmVmPSJtYWlsdG86ZGV3ZWxsQGFkZWxwaGlhLm5ldCI+ZGV3ZWxsQGFkZWxwaGlhLm5ldAo8L2E+ Jmd0OyB3cm90ZTo8L3NwYW4+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i Ym9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBw dCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+U3RlcGhhbmUgQm9ydHptZXllciAmbHQ7 Ym9ydHptZXllciBhdCBuaWMgZG90IGZyJmd0OyB3cm90ZTo8YnI+PGJyPiZndDsgQSBnb29kIHRo aW5nIGFib3V0IHZhbGlkaXR5IHRlc3RpbmcgaXMgdGhhdCB5b3UgY2FuIGRpc3BsYXkgdGhlIGZ1 bGwKPGJyPiZndDsgZGVzY3JpcHRpb24sIG5vdCBvbmx5IHRoZSAzLWxldHRlciBjb2RlLiBIb3cg YWJvdXQgdXNpbmcgdGhlIGJ1aWx0LWluPGJyPiZndDsgbGlzdCB0byBkaXNwbGF5IGluIGFuIGh1 bWFuLWZyaWVuZGx5IHdheSB0aGUgc2VtYW50aWNzIG9mIHRoZSB0YWcsPGJyPiZndDsgYmVmb3Jl IGFza2luZyBjb25maXJtYXRpb24/PGJyPiZndDs8YnI+Jmd0OyAlIC4vZGlzcGxheS10YWcgbWFu LU5rb28tR04KPGJyPiZndDsgbWFuLU5rb28tR046IChtYW46IGxhbmd1YWdlICZxdW90O01hbmRp bmdvJnF1b3Q7LCBOa29vOiBzY3JpcHQmbmJzcDsmbmJzcDsmcXVvdDtOJmFtcDsjeDIwMTk7S28m cXVvdDssPGJyPiZndDsgR046IHJlZ2lvbiZuYnNwOyZuYnNwOyZxdW90O0d1aW5lYSZxdW90Oyk8 YnI+PGJyPk1pbmUgZGlzcGxheXM6PGJyPjxicj5TdWJ0YWcgMTogbWFuPGJyPkxhbmd1YWdlIHN1 YnRhZzogTWFuZGluZ28gKHJlZ2lzdGVyZWQgMjAwNS0xMC0xNikKPGJyPjxicj5TdWJ0YWcgMjog Tmtvbzxicj5TY3JpcHQgc3VidGFnOiBOJ0tvIChyZWdpc3RlcmVkIDIwMDUtMTAtMTYpPGJyPjxi cj5TdWJ0YWcgMzogR048YnI+UmVnaW9uIHN1YnRhZzogR3VpbmVhIChyZWdpc3RlcmVkIDIwMDUt MTAtMTYpPGJyPjxicj53aGljaCBpcyBhZG1pdHRlZGx5IGEgbG90IHRvIGFzayBmb3IgYSBicm9h ZC1wdXJwb3NlIGFwcGxpY2F0aW9uIGxpa2UgYTxicj4KYnJvd3Nlci48YnI+PGJyPi0tPGJyPkRv dWcgRXdlbGwmbmJzcDsmbmJzcDsqJm5ic3A7Jm5ic3A7RnVsbGVydG9uLCBDYWxpZm9ybmlhLCBV U0EmbmJzcDsmbmJzcDsqJm5ic3A7Jm5ic3A7UkZDIDQ2NDUmbmJzcDsmbmJzcDsqJm5ic3A7Jm5i c3A7VVROICMxNDxicj48YSBocmVmPSJodHRwOi8vdXNlcnMuYWRlbHBoaWEubmV0L35kZXdlbGwv Ij5odHRwOi8vdXNlcnMuYWRlbHBoaWEubmV0L35kZXdlbGwvPC9hPjxicj48YSBocmVmPSJodHRw Oi8vd3d3MS5pZXRmLm9yZy9odG1sLmNoYXJ0ZXJzL2x0cnUtY2hhcnRlci5odG1sIj4KaHR0cDov L3d3dzEuaWV0Zi5vcmcvaHRtbC5jaGFydGVycy9sdHJ1LWNoYXJ0ZXIuaHRtbDwvYT48YnI+PGEg aHJlZj0iaHR0cDovL3d3dy5hbHZlc3RyYW5kLm5vL21haWxtYW4vbGlzdGluZm8vaWV0Zi1sYW5n dWFnZXMiPmh0dHA6Ly93d3cuYWx2ZXN0cmFuZC5uby9tYWlsbWFuL2xpc3RpbmZvL2lldGYtbGFu Z3VhZ2VzPC9hPjxicj48YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCjxicj5MdHJ1IG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86THRy dUBpZXRmLm9yZyI+THRydUBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydSI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbHRydTwvYT48YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4K ------=_Part_19391_11066822.1159295332075-- --===============1490049852== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1490049852==-- From ltru-bounces@ietf.org Wed Sep 27 11:52:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSbhU-0005sZ-3u; Wed, 27 Sep 2006 11:51:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSbhT-0005sU-13 for ltru@ietf.org; Wed, 27 Sep 2006 11:51:55 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSbhP-0004rg-OI for ltru@ietf.org; Wed, 27 Sep 2006 11:51:55 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GSbhH-0006uP-P0; Wed, 27 Sep 2006 11:51:43 -0400 Date: Wed, 27 Sep 2006 11:51:43 -0400 To: Frank Ellermann Message-ID: <20060927155143.GI22233@ccil.org> References: <45193FC2.26E2@xyzzy.claranet.de> <20060926185837.GB20579@ccil.org> <451A335A.56DC@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <451A335A.56DC@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ltru@ietf.org Subject: [Ltru] Suppress-Script batch 1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > Here's a list of 67 differences between LTRU and CLDR 1.4 Okay. I've taken Frank's list and pruned it as follows: (a) the four cases where CLDR has multiple scripts and LSR has one; (b) the language collections; (c) Uighur, which Wikipedia says is written in multiple scripts. Please, everyone (especially Michael, when he recovers), review these. Remember that the criterion for including a Suppress-Script is that the script is always used for the language except in a few highly restricted domains, such as writing for the blind, scholarly transliteration, transcription for use in another language, and when the standard script is not available. aa Afar Latn ak Akan Latn bo Tibetan Tibt byn Blin Bilin Ethi ee Ewe Latn fil Filipino Pilipino Latn fur Friulian Latn fy Western Frisian Latn gaa Ga Latn gd Gaelic Scottish Gaelic Latn gez Geez Ethi gsw Swiss German Alemanic Latn haw Hawaiian Latn ho Hiri Motu Latn ia Interlingua de IALA Latn ig Igbo Latn kam Kamba Latn kpe Kpelle Latn kw Cornish Latn mi Maori Latn oc Occitan Provençal Latn os Ossetian Ossetic Latn rm Raeto-Romance Latn sa Sanskrit Deva se Northern Sami Latn sid Sidamo Latn sma Southern Sami Latn smj Lule Sami Latn smn Inari Sami Latn sms Skolt Sami Latn syr Syriac Syrc tet Tetum Latn tig Tigre Ethi tt Tatar Cyrl wal Walamo Ethi yo Yoruba Latn -- I am expressing my opinion. When my John Cowan honorable and gallant friend is called, cowan@ccil.org he will express his opinion. This is http://www.ccil.org/~cowan the process which we call Debate. --Winston Churchill _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 27 12:06:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSbve-0007MX-Ox; Wed, 27 Sep 2006 12:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSbve-0007Lk-FB for ltru@ietf.org; Wed, 27 Sep 2006 12:06:34 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSbvd-0006kX-25 for ltru@ietf.org; Wed, 27 Sep 2006 12:06:34 -0400 Received: from [10.72.72.32] (snvvpn1-10-72-72-c32.corp.yahoo.com [10.72.72.32]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8RG67iJ031285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Sep 2006 09:06:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=LizzrXdNN3JJ9emp7w0+FwR5K8Dtwsd9sqrFrqEmF4iBQen9mR/qSiHMYj7qrnDs Message-ID: <451AA170.4070902@yahoo-inc.com> Date: Wed, 27 Sep 2006 09:06:08 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Suppress-Script batch 1 References: <45193FC2.26E2@xyzzy.claranet.de> <20060926185837.GB20579@ccil.org> <451A335A.56DC@xyzzy.claranet.de> <20060927155143.GI22233@ccil.org> In-Reply-To: <20060927155143.GI22233@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Frank Ellermann , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Here's my thought: -1 to all of them I still believe that Suppress-Script was the wrong solution to the script subtag problem. Here we are seeing *exactly* the kinds of problems with it that I predicted, which is that it is very difficult indeed to make a complete, comprehensive, and verifiably correct list. Furthermore, the possibility of abuse is clearly present. I see 'tt' on the list below, despite someone's vehement belief that Tatar speakers wish to write using the Latin script and are being suppressed. Suppress-Script would aid that, if that case turns out to be true. We would be far better off, in my opinion, to have gone down the other course: a Require-Script field and strong language in RFC 4646 saying, in effect, "You MUST NOT use a script subtag unless the language or extlang has a Require-Script matching the script used in the content or the script subtag identifies some distinction in the content being tagged." This latter course would meet all of the objections to Suppress-Script, including that it precludes certain kinds of abuse, either premeditated or accidental. Since we didn't do that, I think we should only create Suppress-Script fields when there is clear and compelling reason to do so... and I think that a clear and compelling reason for me would be someone requesting it on purpose. Addison John Cowan wrote: > Frank Ellermann scripsit: > >> Here's a list of 67 differences between LTRU and CLDR 1.4 > > Okay. I've taken Frank's list and pruned it as follows: (a) the four > cases where CLDR has multiple scripts and LSR has one; (b) the language > collections; (c) Uighur, which Wikipedia says is written in multiple > scripts. > > Please, everyone (especially Michael, when he recovers), review these. > Remember that the criterion for including a Suppress-Script is that the > script is always used for the language except in a few highly restricted > domains, such as writing for the blind, scholarly transliteration, > transcription for use in another language, and when the standard script > is not available. > > aa Afar Latn > ak Akan Latn > bo Tibetan Tibt > byn Blin Bilin Ethi > ee Ewe Latn > fil Filipino Pilipino Latn > fur Friulian Latn > fy Western Frisian Latn > gaa Ga Latn > gd Gaelic Scottish Gaelic Latn > gez Geez Ethi > gsw Swiss German Alemanic Latn > haw Hawaiian Latn > ho Hiri Motu Latn > ia Interlingua de IALA Latn > ig Igbo Latn > kam Kamba Latn > kpe Kpelle Latn > kw Cornish Latn > mi Maori Latn > oc Occitan Provençal Latn > os Ossetian Ossetic Latn > rm Raeto-Romance Latn > sa Sanskrit Deva > se Northern Sami Latn > sid Sidamo Latn > sma Southern Sami Latn > smj Lule Sami Latn > smn Inari Sami Latn > sms Skolt Sami Latn > syr Syriac Syrc > tet Tetum Latn > tig Tigre Ethi > tt Tatar Cyrl > wal Walamo Ethi > yo Yoruba Latn > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 27 13:15:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSd0B-0006ab-6f; Wed, 27 Sep 2006 13:15:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSd0A-0006aW-1g for ltru@ietf.org; Wed, 27 Sep 2006 13:15:18 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSd07-0007IC-7R for ltru@ietf.org; Wed, 27 Sep 2006 13:15:18 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060927171512.VJMV5459.mta9.adelphia.net@DGBP7M81> for ; Wed, 27 Sep 2006 13:15:12 -0400 Message-ID: <030301c6e258$7e923bb0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Wed, 27 Sep 2006 10:15:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Re: Suppress-Script batch 1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Remember that the criterion for including a Suppress-Script is that > the script is always used for the language except in a few highly > restricted domains, such as writing for the blind, scholarly > transliteration, transcription for use in another language, and when > the standard script is not available. I wish we had that explanation somewhere in RFC 4646. It's better than most of the explanations I've seen, certainly better than any I've written. -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 27 13:53:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSdbN-00033Y-74; Wed, 27 Sep 2006 13:53:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSdbL-00033R-AV for ltru@ietf.org; Wed, 27 Sep 2006 13:53:43 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound2-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSdbF-0004bD-Gg for ltru@ietf.org; Wed, 27 Sep 2006 13:53:43 -0400 Received: from outbound2-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-cpk-R.bigfish.com (Postfix) with ESMTP id CA0AC71A741; Wed, 27 Sep 2006 17:53:19 +0000 (UTC) Received: from mail108-cpk-R.bigfish.com (unknown [192.168.21.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound2-cpk.bigfish.com (Postfix) with ESMTP id 99B8F71A73C; Wed, 27 Sep 2006 17:53:19 +0000 (UTC) Received: from mail108-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail108-cpk-R.bigfish.com (Postfix) with ESMTP id EEDF95C82C5; Wed, 27 Sep 2006 17:53:18 +0000 (UTC) X-BigFish: VP Received: by mail108-cpk (MessageSwitch) id 1159379598892864_8726; Wed, 27 Sep 2006 17:53:18 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail108-cpk.bigfish.com (Postfix) with ESMTP id C52C05C8202; Wed, 27 Sep 2006 17:53:18 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2006092710561577-1571848 ; Wed, 27 Sep 2006 10:56:15 -0700 In-Reply-To: <030301c6e258$7e923bb0$6401a8c0@DGBP7M81> To: "Doug Ewell" , "LTRU Working Group" Subject: Re: [Ltru] Re: Suppress-Script batch 1 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Wed, 27 Sep 2006 10:52:08 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 09/27/2006 10:52:08, Serialize complete at 09/27/2006 10:52:08, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 09/27/2006 10:56:15 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 09/27/2006 10:56:16 AM, Serialize complete at 09/27/2006 10:56:16 AM X-Spam-Score: 0.3 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0584512456==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0584512456== Content-Type: multipart/alternative; boundary="=_alternative 006242E5882571F6_=" This is a multipart message in MIME format. --=_alternative 006242E5882571F6_= Content-Type: text/plain; charset="US-ASCII" I still think the text of RFC 4646 and structure leans strongly toward an assumption that all language is written. Increasingly web content features animated talking heads or video, and this content may need language tagging as well. Motion picture applications -- including television, broadcast, Digital Cinema, podcast, phonecast, multilingual electronic program guides, and local/national/university archives -- also require language tagging. The text of RFC 4646 indicates that the script can be omitted when it can be assumed. It doesn't mention that in an increasing number of cases, the assignment of a script tag is completely inappropriate. Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment "Doug Ewell" 09/27/2006 10:15 AM To "LTRU Working Group" cc Subject [Ltru] Re: Suppress-Script batch 1 John Cowan wrote: > Remember that the criterion for including a Suppress-Script is that > the script is always used for the language except in a few highly > restricted domains, such as writing for the blind, scholarly > transliteration, transcription for use in another language, and when > the standard script is not available. I wish we had that explanation somewhere in RFC 4646. It's better than most of the explanations I've seen, certainly better than any I've written. -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 006242E5882571F6_= Content-Type: text/html; charset="US-ASCII"
I still think the text of RFC 4646 and structure leans strongly toward an assumption that all language is written. Increasingly web content features animated talking heads or video, and this content may need language tagging as well.

Motion picture applications -- including television, broadcast, Digital Cinema, podcast, phonecast, multilingual electronic program guides, and local/national/university archives -- also require language tagging. The text of RFC 4646 indicates that the script can be omitted when it can be assumed. It doesn't mention that in an increasing number of cases, the assignment of a script tag is completely inappropriate.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment





"Doug Ewell" <dewell@adelphia.net>

09/27/2006 10:15 AM

To
"LTRU Working Group" <ltru@ietf.org>
cc
Subject
[Ltru] Re: Suppress-Script batch 1





John Cowan <cowan at ccil dot org> wrote:

> Remember that the criterion for including a Suppress-Script is that
> the script is always used for the language except in a few highly
> restricted domains, such as writing for the blind, scholarly
> transliteration, transcription for use in another language, and when
> the standard script is not available.

I wish we had that explanation somewhere in RFC 4646.  It's better than
most of the explanations I've seen, certainly better than any I've
written.

--
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
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 006242E5882571F6_=-- --===============0584512456== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0584512456==-- From ltru-bounces@ietf.org Wed Sep 27 14:07:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSdol-0002Eo-OU; Wed, 27 Sep 2006 14:07:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSdo5-00021t-37 for ltru@ietf.org; Wed, 27 Sep 2006 14:06:53 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSdo2-0006Io-NG for ltru@ietf.org; Wed, 27 Sep 2006 14:06:53 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060927180650.UXJN437.mta13.adelphia.net@DGBP7M81>; Wed, 27 Sep 2006 14:06:50 -0400 Message-ID: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" , Date: Wed, 27 Sep 2006 11:06:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Subject: [Ltru] Re: Suppress-Script batch 1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org (Cross-posted to ietf-languages, since it really belongs there.) Addison Phillips wrote: > Here's my thought: > > -1 to all of them > > I still believe that Suppress-Script was the wrong solution to the > script subtag problem. Here we are seeing *exactly* the kinds of > problems with it that I predicted, which is that it is very difficult > indeed to make a complete, comprehensive, and verifiably correct list. We can't put that particular toothpaste back into that particular tube. By creating an initial set of 126 Suppress-Script entries, I'm afraid the stage is set to investigate the remaining RFC 3066-era languages, and either add Suppress-Scripts or not. > Furthermore, the possibility of abuse is clearly present. I see 'tt' > on the list below, despite someone's vehement belief that Tatar > speakers wish to write using the Latin script and are being > suppressed. Suppress-Script would aid that, if that case turns out to > be true. This is a good observation, and it's why John urged everyone to review his list. For the kind of bulk update that John and others have in mind, we (ietf-languages) would probably have to raise the bar for acceptance even higher, something like "Language A written in Script B would be just plain bizarre." Last March I began a small research project to determine whether Korean should have a Suppress-Script of Hangul. I read books, scanned Korean-language newspapers published in Seoul and in Los Angeles, checked numerous Web sites, talked to native Korean speakers in person and by e-mail. The result was that Hangul is, in fact, used an overwhelming proportion of the time to write modern Korean -- a colleague at work actually used the word "overwhelming" -- but there is still a certain, tiny, regular pattern of usage of Han (hanja) in scholarly works and newspapers. "Regular" was the key here. So I concluded that a Suppress-Script for Korean actually would NOT be a good idea, which is not what I expected to find. One important fact to keep in mind is that Suppress-Script values may be not only added, but also removed (Section 3.4, item 7). If we make a mistake, we can go back and fix it. > Since we didn't do that [Accept-Script], I think we should only create > Suppress-Script fields when there is clear and compelling reason to do > so... and I think that a clear and compelling reason for me would be > someone requesting it on purpose. Like all other requests, though, it needs to be confirmed that such a request relates to actual usage, and is not a "test" of the system or an attempt to "prove" something about the system or its participants or related SDOs. -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 27 14:20:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSe1B-0001k0-90; Wed, 27 Sep 2006 14:20:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSe19-0001ju-Ci for ltru@ietf.org; Wed, 27 Sep 2006 14:20:23 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSe18-00015p-2h for ltru@ietf.org; Wed, 27 Sep 2006 14:20:23 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060927182021.VQOC437.mta13.adelphia.net@DGBP7M81>; Wed, 27 Sep 2006 14:20:21 -0400 Message-ID: <031a01c6e261$98a5b6e0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Re: Suppress-Script batch 1 Date: Wed, 27 Sep 2006 11:20:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Karen_Broome@spe.sony.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Karen Broome wrote: > I still think the text of RFC 4646 and structure leans strongly toward > an assumption that all language is written. Increasingly web content > features animated talking heads or video, and this content may need > language tagging as well. > > Motion picture applications -- including television, broadcast, > Digital Cinema, podcast, phonecast, multilingual electronic program > guides, and local/national/university archives -- also require > language tagging. The text of RFC 4646 indicates that the script can > be omitted when it can be assumed. It doesn't mention that in an > increasing number of cases, the assignment of a script tag is > completely inappropriate. This was probably meant to be covered in the introduction to Section 2.2.3, which says, "Script subtags are used to indicate the script or writing system variations that distinguish the written forms of a language or its dialects." While this describes the use case, I agree with Karen that the "non-use" case is not adequately addressed. As John Cowan observed on ietf-languages, some users may select subtags simply to "fill in the blanks" even when they add no distinguishing value. Sections 2.2.3 and 4.1 seem like appropriate places to add this. -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 27 15:11:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSeoR-0005Ag-Ap; Wed, 27 Sep 2006 15:11:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSeoQ-0005Ab-LX for ltru@ietf.org; Wed, 27 Sep 2006 15:11:18 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSeoO-0008OB-6P for ltru@ietf.org; Wed, 27 Sep 2006 15:11:18 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8RJB2Dm042092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Sep 2006 12:11:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=C1AzR43k0xzwuZ9H8FNRA256qPLPVjpnMIchFim4ADWwZMqdmFtnoD0eY6ZTOYWj Message-ID: <451ACCC5.6010609@yahoo-inc.com> Date: Wed, 27 Sep 2006 12:11:01 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Doug Ewell References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> In-Reply-To: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: LTRU Working Group Subject: [Ltru] Re: Suppress-Script batch 1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > (Cross-posted to ietf-languages, since it really belongs there.) It does NOT belong there. I object in the strongest possible terms to my being cross-posted, especially in an edited form. > > Addison Phillips wrote: > >> Here's my thought: >> >> -1 to all of them >> >> I still believe that Suppress-Script was the wrong solution to the >> script subtag problem. Here we are seeing *exactly* the kinds of >> problems with it that I predicted, which is that it is very difficult >> indeed to make a complete, comprehensive, and verifiably correct list. > > We can't put that particular toothpaste back into that particular tube. > By creating an initial set of 126 Suppress-Script entries, I'm afraid > the stage is set to investigate the remaining RFC 3066-era languages, > and either add Suppress-Scripts or not. Yeah, I lost that battle and don't really want to revisit it... except that I am horrified to note that my predictions about the unwieldy nature of Suppress-Script all came true. I do not believe that ietf-languages is the right forum for deciding how languages are written customarily and would prefer it if only the absolutely necessary Suppress-Script fields were created. I also believe that, since we appear to be willing to consider trashing any amount of RFC 4646 in a quest to have a better file format (XML) or a different reviewing mechanism (LSRB), why not fix everything to our current taste? I don't want to be alone in standing on the barricades fighting extraneous change. :-) > >> Furthermore, the possibility of abuse is clearly present. I see 'tt' >> on the list below, despite someone's vehement belief that Tatar >> speakers wish to write using the Latin script and are being >> suppressed. Suppress-Script would aid that, if that case turns out to >> be true. > > This is a good observation, and it's why John urged everyone to review > his list. For the kind of bulk update that John and others have in > mind, we (ietf-languages) would probably have to raise the bar for > acceptance even higher, something like "Language A written in Script B > would be just plain bizarre." It is exactly why Suppress-Script is an awful solution to the problem of preventing unwanted script subtags. Too much information is required about too many languages. Most languages are customarily written in only one script, but determining which ones that is true of and what the script subtag should be is moderately difficult, especially for languages of limited diffusion. By contrast, determining which small number of languages are customarily written in more than one script (Note Well: the word 'customarily'!) is a far easier task. > > Last March I began a small research project to determine whether Korean > should have a Suppress-Script of Hangul. I read books, scanned > Korean-language newspapers published in Seoul and in Los Angeles, > checked numerous Web sites, talked to native Korean speakers in person > and by e-mail. The result was that Hangul is, in fact, used an > overwhelming proportion of the time to write modern Korean -- a > colleague at work actually used the word "overwhelming" -- but there is > still a certain, tiny, regular pattern of usage of Han (hanja) in > scholarly works and newspapers. "Regular" was the key here. So I > concluded that a Suppress-Script for Korean actually would NOT be a good > idea, which is not what I expected to find. It took a lot of work to arrive at that conclusion, no? Why are these other languages different? > > One important fact to keep in mind is that Suppress-Script values may be > not only added, but also removed (Section 3.4, item 7). If we make a > mistake, we can go back and fix it. > >> Since we didn't do that [Accept-Script], I think we should only create >> Suppress-Script fields when there is clear and compelling reason to do >> so... and I think that a clear and compelling reason for me would be >> someone requesting it on purpose. > > Like all other requests, though, it needs to be confirmed that such a > request relates to actual usage, and is not a "test" of the system or an > attempt to "prove" something about the system or its participants or > related SDOs. > This may be difficult to evaluate. For all I know, 'tt' is, in fact, customarily written in Cyrillic and the person proposing Latin script is an outlying opinion. I have no way of evaluating it without finding a large number of documents written in Tatar and examining their script. I've said enough. I think this an awful idea, but no one else seems to see the difficulties involved. So I'm going to quit raising my sour grapes up for general viewing. On the other hand, I note that attempts to create this informative field have already demonstrated some workability problems. So, let's leave it at: -1 for proposing these Suppress-Script fields on ietf-languages, because I don't believe there is enough compelling information to support them. When they are proposed, you can count on my emitting a quiet -1 for each of them. Consensus, after all, is not unanimity. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 27 16:04:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSfdN-0001hH-Vo; Wed, 27 Sep 2006 16:03:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSfdN-0001h7-EI for ltru@ietf.org; Wed, 27 Sep 2006 16:03:57 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSfcz-0000Po-6U for ltru@ietf.org; Wed, 27 Sep 2006 16:03:57 -0400 Received: by nf-out-0910.google.com with SMTP id n15so594135nfc for ; Wed, 27 Sep 2006 13:03:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=hYqjNDYu2ETAt/ymAYzFjm0BB0ewoi28zlbGeG5B/H+ie5sdKuBbwUoB5lHd5aq0vASxKvTzQSkFT8koYihFQmxqmdAXSBgDL5dt+JWToGjEuUedAMOQtTiy7W3JnOOpgAoYM8rQuxI2kLCP5X7ljXO4JA7j9Dm9OjBm8chDOSE= Received: by 10.49.29.3 with SMTP id g3mr2836868nfj; Wed, 27 Sep 2006 13:03:30 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Wed, 27 Sep 2006 13:03:29 -0700 (PDT) Message-ID: <30b660a20609271303v3a32049en69b551d5e92468f7@mail.gmail.com> Date: Wed, 27 Sep 2006 13:03:29 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Re: Suppress-Script batch 1 In-Reply-To: <451ACCC5.6010609@yahoo-inc.com> MIME-Version: 1.0 References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <451ACCC5.6010609@yahoo-inc.com> X-Google-Sender-Auth: 85855c8d7317bbe3 X-Spam-Score: 0.3 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0104991557==" Errors-To: ltru-bounces@ietf.org --===============0104991557== Content-Type: multipart/alternative; boundary="----=_Part_6752_25126226.1159387409915" ------=_Part_6752_25126226.1159387409915 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I also agree that suppress script was a bad idea. Better would have been an informative field indicating that "this language is customarily written in multiple scripts"; that would provide the indication that a script might be necessary. (Notice that in lookup matching -- our principal concern -- we end up always logically having a "default script" even for languages customarily written in multiple scripts -- that is the script we will use for content that matches the case where the language tag doesn't contain a script. For that matter, we also always have a "default region" in that sense; the content is appropriate for the region that is most populous for that language.) Mark On 9/27/06, Addison Phillips wrote: > > > > Doug Ewell wrote: > > (Cross-posted to ietf-languages, since it really belongs there.) > > It does NOT belong there. I object in the strongest possible terms to my > being cross-posted, especially in an edited form. > > > > > > Addison Phillips wrote: > > > >> Here's my thought: > >> > >> -1 to all of them > >> > >> I still believe that Suppress-Script was the wrong solution to the > >> script subtag problem. Here we are seeing *exactly* the kinds of > >> problems with it that I predicted, which is that it is very difficult > >> indeed to make a complete, comprehensive, and verifiably correct list. > > > > We can't put that particular toothpaste back into that particular tube. > > By creating an initial set of 126 Suppress-Script entries, I'm afraid > > the stage is set to investigate the remaining RFC 3066-era languages, > > and either add Suppress-Scripts or not. > > Yeah, I lost that battle and don't really want to revisit it... except > that I am horrified to note that my predictions about the unwieldy > nature of Suppress-Script all came true. I do not believe that > ietf-languages is the right forum for deciding how languages are written > customarily and would prefer it if only the absolutely necessary > Suppress-Script fields were created. > > I also believe that, since we appear to be willing to consider trashing > any amount of RFC 4646 in a quest to have a better file format (XML) or > a different reviewing mechanism (LSRB), why not fix everything to our > current taste? I don't want to be alone in standing on the barricades > fighting extraneous change. :-) > > > > >> Furthermore, the possibility of abuse is clearly present. I see 'tt' > >> on the list below, despite someone's vehement belief that Tatar > >> speakers wish to write using the Latin script and are being > >> suppressed. Suppress-Script would aid that, if that case turns out to > >> be true. > > > > This is a good observation, and it's why John urged everyone to review > > his list. For the kind of bulk update that John and others have in > > mind, we (ietf-languages) would probably have to raise the bar for > > acceptance even higher, something like "Language A written in Script B > > would be just plain bizarre." > > It is exactly why Suppress-Script is an awful solution to the problem of > preventing unwanted script subtags. Too much information is required > about too many languages. Most languages are customarily written in only > one script, but determining which ones that is true of and what the > script subtag should be is moderately difficult, especially for > languages of limited diffusion. > > By contrast, determining which small number of languages are customarily > written in more than one script (Note Well: the word 'customarily'!) is > a far easier task. > > > > > Last March I began a small research project to determine whether Korean > > should have a Suppress-Script of Hangul. I read books, scanned > > Korean-language newspapers published in Seoul and in Los Angeles, > > checked numerous Web sites, talked to native Korean speakers in person > > and by e-mail. The result was that Hangul is, in fact, used an > > overwhelming proportion of the time to write modern Korean -- a > > colleague at work actually used the word "overwhelming" -- but there is > > still a certain, tiny, regular pattern of usage of Han (hanja) in > > scholarly works and newspapers. "Regular" was the key here. So I > > concluded that a Suppress-Script for Korean actually would NOT be a good > > idea, which is not what I expected to find. > > It took a lot of work to arrive at that conclusion, no? Why are these > other languages different? > > > > > One important fact to keep in mind is that Suppress-Script values may be > > not only added, but also removed (Section 3.4, item 7). If we make a > > mistake, we can go back and fix it. > > > >> Since we didn't do that [Accept-Script], I think we should only create > >> Suppress-Script fields when there is clear and compelling reason to do > >> so... and I think that a clear and compelling reason for me would be > >> someone requesting it on purpose. > > > > Like all other requests, though, it needs to be confirmed that such a > > request relates to actual usage, and is not a "test" of the system or an > > attempt to "prove" something about the system or its participants or > > related SDOs. > > > > This may be difficult to evaluate. For all I know, 'tt' is, in fact, > customarily written in Cyrillic and the person proposing Latin script is > an outlying opinion. I have no way of evaluating it without finding a > large number of documents written in Tatar and examining their script. > > I've said enough. I think this an awful idea, but no one else seems to > see the difficulties involved. So I'm going to quit raising my sour > grapes up for general viewing. On the other hand, I note that attempts > to create this informative field have already demonstrated some > workability problems. > > So, let's leave it at: > > -1 for proposing these Suppress-Script fields on ietf-languages, > because I don't believe there is enough compelling information to > support them. > > When they are proposed, you can count on my emitting a quiet -1 for each > of them. Consensus, after all, is not unanimity. > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_6752_25126226.1159387409915 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I also agree that suppress script was a bad idea. Better would have been an informative field indicating that "this language is customarily written in multiple scripts"; that would provide the indication that a script might be necessary.

(Notice that in lookup matching -- our principal concern -- we end up always logically having a "default script" even for languages customarily written in multiple scripts -- that is the script we will use for content that matches the case where the language tag doesn't contain a script. For that matter, we also always have a "default region" in that sense; the content is appropriate for the region that is most populous for that language.)

Mark

On 9/27/06, Addison Phillips <addison@yahoo-inc.com> wrote:


Doug Ewell wrote:
> (Cross-posted to ietf-languages, since it really belongs there.)

It does NOT belong there. I object in the strongest possible terms to my
being cross-posted, especially in an edited form.


>
> Addison Phillips <addison at yahoo dash inc dot com> wrote:
>
>> Here's my thought:
>>
>>   -1 to all of them
>>
>> I still believe that Suppress-Script was the wrong solution to the
>> script subtag problem. Here we are seeing *exactly* the kinds of
>> problems with it that I predicted, which is that it is very difficult
>> indeed to make a complete, comprehensive, and verifiably correct list.
>
> We can't put that particular toothpaste back into that particular tube.
> By creating an initial set of 126 Suppress-Script entries, I'm afraid
> the stage is set to investigate the remaining RFC 3066-era languages,
> and either add Suppress-Scripts or not.

Yeah, I lost that battle and don't really want to revisit it... except
that I am horrified to note that my predictions about the unwieldy
nature of Suppress-Script all came true. I do not believe that
ietf-languages is the right forum for deciding how languages are written
customarily and would prefer it if only the absolutely necessary
Suppress-Script fields were created.

I also believe that, since we appear to be willing to consider trashing
any amount of RFC 4646 in a quest to have a better file format (XML) or
a different reviewing mechanism (LSRB), why not fix everything to our
current taste? I don't want to be alone in standing on the barricades
fighting extraneous change. :-)

>
>> Furthermore, the possibility of abuse is clearly present. I see 'tt'
>> on the list below, despite someone's vehement belief that Tatar
>> speakers wish to write using the Latin script and are being
>> suppressed. Suppress-Script would aid that, if that case turns out to
>> be true.
>
> This is a good observation, and it's why John urged everyone to review
> his list.  For the kind of bulk update that John and others have in
> mind, we (ietf-languages) would probably have to raise the bar for
> acceptance even higher, something like "Language A written in Script B
> would be just plain bizarre."

It is exactly why Suppress-Script is an awful solution to the problem of
preventing unwanted script subtags. Too much information is required
about too many languages. Most languages are customarily written in only
one script, but determining which ones that is true of and what the
script subtag should be is moderately difficult, especially for
languages of limited diffusion.

By contrast, determining which small number of languages are customarily
written in more than one script (Note Well: the word 'customarily'!) is
a far easier task.

>
> Last March I began a small research project to determine whether Korean
> should have a Suppress-Script of Hangul.  I read books, scanned
> Korean-language newspapers published in Seoul and in Los Angeles,
> checked numerous Web sites, talked to native Korean speakers in person
> and by e-mail.  The result was that Hangul is, in fact, used an
> overwhelming proportion of the time to write modern Korean -- a
> colleague at work actually used the word "overwhelming" -- but there is
> still a certain, tiny, regular pattern of usage of Han (hanja) in
> scholarly works and newspapers.  "Regular" was the key here.  So I
> concluded that a Suppress-Script for Korean actually would NOT be a good
> idea, which is not what I expected to find.

It took a lot of work to arrive at that conclusion, no? Why are these
other languages different?

>
> One important fact to keep in mind is that Suppress-Script values may be
> not only added, but also removed (Section 3.4, item 7).  If we make a
> mistake, we can go back and fix it.
>
>> Since we didn't do that [Accept-Script], I think we should only create
>> Suppress-Script fields when there is clear and compelling reason to do
>> so... and I think that a clear and compelling reason for me would be
>> someone requesting it on purpose.
>
> Like all other requests, though, it needs to be confirmed that such a
> request relates to actual usage, and is not a "test" of the system or an
> attempt to "prove" something about the system or its participants or
> related SDOs.
>

This may be difficult to evaluate. For all I know, 'tt' is, in fact,
customarily written in Cyrillic and the person proposing Latin script is
an outlying opinion. I have no way of evaluating it without finding a
large number of documents written in Tatar and examining their script.

I've said enough. I think this an awful idea, but no one else seems to
see the difficulties involved. So I'm going to quit raising my sour
grapes up for general viewing. On the other hand, I note that attempts
to create this informative field have already demonstrated some
workability problems.

So, let's leave it at:

   -1 for proposing these Suppress-Script fields on ietf-languages,
because I don't believe there is enough compelling information to
support them.

When they are proposed, you can count on my emitting a quiet -1 for each
of them. Consensus, after all, is not unanimity.

Addison

--
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

------=_Part_6752_25126226.1159387409915-- --===============0104991557== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0104991557==-- From ltru-bounces@ietf.org Wed Sep 27 16:05:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSfeR-0002Tl-1N; Wed, 27 Sep 2006 16:05:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSfeP-0002TW-TR for ltru@ietf.org; Wed, 27 Sep 2006 16:05:01 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSfeJ-0000cE-9t for ltru@ietf.org; Wed, 27 Sep 2006 16:05:01 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004800086.msg for ; Wed, 27 Sep 2006 21:06:43 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Wed, 27 Sep 2006 21:05:01 +0100 From: "Debbie Garside" To: "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Re: Suppress-Script batch 1 Date: Wed, 27 Sep 2006 21:04:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcbiaPHt1xq8wOyzTdKb0GJXh3WqlAAA0KVQ In-Reply-To: <451ACCC5.6010609@yahoo-inc.com> Message-ID: <1781F6A91E3F4F75B7F62DA4F99A4565.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Wed, 27 Sep 2006 21:06:43 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Wed, 27 Sep 2006 21:06:44 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I have to say, I am mostly in agreement with Addison. I haven't time to go into details on this now, but I have done extensive research on a number of languages and their writing systems. It is not as easy as it sounds and really needs thorough research or the Registry is going to be in trouble. A few weeks ago I corrected a Unicode document that was displaying two separate languages of the same name, spoken in different regions with scripts designated. The script information was correct for one of the languages only. This type of error highlights the muddle that can be created by "official" documentation compiled without adequate research. On this occasion a simple human error could be easily corrected. This is not the case within the Registry. I do realise that nothing is ever 100% accurate, and certainly linguistics is a field where there are a number of differing opinions within various aspects; no one of them being necessarily correct. But I also think that if we are to consider seriously supporting suppress-script within the Registry a thorough methodology should be devised in order to deal with this. As within many aspects of business today, we can design out the error rating insofar as is reasonably possible. However, I do not think that research of this nature is within the remit of LTRU or IETF-languages. I know suppress-script is there now and I have no suggestions to make to repair this decision other than to only add suppress-script on request and when presented with "thorough" supporting research; "thorough" should be defined in RFC4646bis. Best regards Debbie Garside > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 27 September 2006 20:11 > To: Doug Ewell > Cc: LTRU Working Group > Subject: [Ltru] Re: Suppress-Script batch 1 > > > > Doug Ewell wrote: > > (Cross-posted to ietf-languages, since it really belongs there.) > > It does NOT belong there. I object in the strongest possible > terms to my being cross-posted, especially in an edited form. > > > > > > Addison Phillips wrote: > > > >> Here's my thought: > >> > >> -1 to all of them > >> > >> I still believe that Suppress-Script was the wrong solution to the > >> script subtag problem. Here we are seeing *exactly* the kinds of > >> problems with it that I predicted, which is that it is > very difficult > >> indeed to make a complete, comprehensive, and verifiably > correct list. > > > > We can't put that particular toothpaste back into that > particular tube. > > By creating an initial set of 126 Suppress-Script entries, > I'm afraid > > the stage is set to investigate the remaining RFC 3066-era > languages, > > and either add Suppress-Scripts or not. > > Yeah, I lost that battle and don't really want to revisit > it... except > that I am horrified to note that my predictions about the unwieldy > nature of Suppress-Script all came true. I do not believe that > ietf-languages is the right forum for deciding how languages > are written > customarily and would prefer it if only the absolutely necessary > Suppress-Script fields were created. > > I also believe that, since we appear to be willing to > consider trashing > any amount of RFC 4646 in a quest to have a better file > format (XML) or > a different reviewing mechanism (LSRB), why not fix everything to our > current taste? I don't want to be alone in standing on the barricades > fighting extraneous change. :-) > > > > >> Furthermore, the possibility of abuse is clearly present. > I see 'tt' > >> on the list below, despite someone's vehement belief that Tatar > >> speakers wish to write using the Latin script and are being > >> suppressed. Suppress-Script would aid that, if that case > turns out to > >> be true. > > > > This is a good observation, and it's why John urged > everyone to review > > his list. For the kind of bulk update that John and others have in > > mind, we (ietf-languages) would probably have to raise the bar for > > acceptance even higher, something like "Language A written > in Script B > > would be just plain bizarre." > > It is exactly why Suppress-Script is an awful solution to the > problem of > preventing unwanted script subtags. Too much information is required > about too many languages. Most languages are customarily > written in only > one script, but determining which ones that is true of and what the > script subtag should be is moderately difficult, especially for > languages of limited diffusion. > > By contrast, determining which small number of languages are > customarily > written in more than one script (Note Well: the word > 'customarily'!) is > a far easier task. > > > > > Last March I began a small research project to determine > whether Korean > > should have a Suppress-Script of Hangul. I read books, scanned > > Korean-language newspapers published in Seoul and in Los Angeles, > > checked numerous Web sites, talked to native Korean > speakers in person > > and by e-mail. The result was that Hangul is, in fact, used an > > overwhelming proportion of the time to write modern Korean -- a > > colleague at work actually used the word "overwhelming" -- > but there is > > still a certain, tiny, regular pattern of usage of Han (hanja) in > > scholarly works and newspapers. "Regular" was the key here. So I > > concluded that a Suppress-Script for Korean actually would > NOT be a good > > idea, which is not what I expected to find. > > It took a lot of work to arrive at that conclusion, no? Why are these > other languages different? > > > > > One important fact to keep in mind is that Suppress-Script > values may be > > not only added, but also removed (Section 3.4, item 7). If > we make a > > mistake, we can go back and fix it. > > > >> Since we didn't do that [Accept-Script], I think we should > only create > >> Suppress-Script fields when there is clear and compelling > reason to do > >> so... and I think that a clear and compelling reason for > me would be > >> someone requesting it on purpose. > > > > Like all other requests, though, it needs to be confirmed > that such a > > request relates to actual usage, and is not a "test" of the > system or an > > attempt to "prove" something about the system or its > participants or > > related SDOs. > > > > This may be difficult to evaluate. For all I know, 'tt' is, in fact, > customarily written in Cyrillic and the person proposing > Latin script is > an outlying opinion. I have no way of evaluating it without finding a > large number of documents written in Tatar and examining their script. > > I've said enough. I think this an awful idea, but no one else > seems to > see the difficulties involved. So I'm going to quit raising my sour > grapes up for general viewing. On the other hand, I note that > attempts > to create this informative field have already demonstrated some > workability problems. > > So, let's leave it at: > > -1 for proposing these Suppress-Script fields on ietf-languages, > because I don't believe there is enough compelling information to > support them. > > When they are proposed, you can count on my emitting a quiet > -1 for each > of them. Consensus, after all, is not unanimity. > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 27 16:16:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSfpX-0008Gb-Bb; Wed, 27 Sep 2006 16:16:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSfpW-0008GC-R1 for ltru@ietf.org; Wed, 27 Sep 2006 16:16:30 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSfpI-00036k-Rw for ltru@ietf.org; Wed, 27 Sep 2006 16:16:30 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060927201616.NBOP28964.mta10.adelphia.net@DGBP7M81>; Wed, 27 Sep 2006 16:16:16 -0400 Message-ID: <034701c6e271$c9fb9dd0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <451ACCC5.6010609@yahoo-inc.com> Date: Wed, 27 Sep 2006 13:16:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Subject: [Ltru] Re: Suppress-Script batch 1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >> (Cross-posted to ietf-languages, since it really belongs there.) > > It does NOT belong there. I object in the strongest possible terms to > my being cross-posted, especially in an edited form. OK, I apologize. I thought ietf-languages was where decisions were made about specific items in the Registry, and LTRU was where the governing documents and policy decisions about them were discussed. I guess this fell on the policy side. > Yeah, I lost that battle and don't really want to revisit it... except > that I am horrified to note that my predictions about the unwieldy > nature of Suppress-Script all came true. I do not believe that > ietf-languages is the right forum for deciding how languages are > written customarily and would prefer it if only the absolutely > necessary Suppress-Script fields were created. I didn't want Suppress-Script, Require-Script, Suggest-Script, or Gently-Nudge-In-The-Drection-Of-Script. I thought the guiding principle was supposed to be "Tag content wisely." > I also believe that, since we appear to be willing to consider > trashing any amount of RFC 4646 in a quest to have a better file > format (XML) or a different reviewing mechanism (LSRB), why not fix > everything to our current taste? I don't want to be alone in standing > on the barricades fighting extraneous change. :-) The only reason I supported XML was that the General Manager of IANA reported they were moving to it. The LSRB basically would codify what we do now -- Michael reviews subtags, I prepare paperwork for him, Harald moderates the list. It would allow life to go on in the event Michael is on one of his extended trips. You're not alone in your frustration -- remember how I feel about extension subtags and the group's reluctance to consider using them for transcriptions or any other purpose. > It is exactly why Suppress-Script is an awful solution to the problem > of preventing unwanted script subtags. Too much information is > required about too many languages. Most languages are customarily > written in only one script, but determining which ones that is true of > and what the script subtag should be is moderately difficult, > especially for languages of limited diffusion. No argument. As I said from the outset, S-S -- more than any other feature of RFC 4646 -- makes it look like we are trying to be the ultimate arbiters of language usage, instead of a body that gathers the research of others and makes it usable in a regularized fashion on the Internet, which is the body I joined. > By contrast, determining which small number of languages are > customarily written in more than one script (Note Well: the word > 'customarily'!) is a far easier task. Even that carries the potential for controversy. Is Santali "customarily" written in Ol Chiki? That probably depends on who you ask. > It took a lot of work to arrive at that [Korean] conclusion, no? Why > are these other languages different? They aren't, necessarily. Some might be less work, some more. This is one reason I don't just starting ticking boxes when a list like John's comes up, like I'm voting for an All-Star team. I don't personally have the expertise to make most of those calls, and they should only be made by those who do. > I've said enough. I think this an awful idea, but no one else seems to > see the difficulties involved. So I'm going to quit raising my sour > grapes up for general viewing. On the other hand, I note that attempts > to create this informative field have already demonstrated some > workability problems. S-S provides a long-term solution for a world that continues to use remove-from-right prefix matching and unnecessary region subtags, instead of using the recommendations in RFC 4647 which would solve all of these problems. We assume that tag producers will start adding script subtags indiscriminately, but that tag consumers will *not* update their matching engines to understand them. > So, let's leave it at: > > -1 for proposing these Suppress-Script fields on ietf-languages, > because I don't believe there is enough compelling information to > support them. > > When they are proposed, you can count on my emitting a quiet -1 for > each of them. Consensus, after all, is not unanimity. Would you support removing some of the ones that are there already? Example: Timne. In order for Suppress-Script to work in the case of Timne, there has to be content currently tagged "tem-SL" (with a region subtag, not just "tem"), and there must be a concern that the content will not be found if it is tagged "tem-Latn-SL" instead (thus using TWO unnecessary subtags instead of one). We added Timne to the initial S-S list, not because this scenario played out, but because it could be easily determined that Timne is written overwhelmingly in Latin script. I don't like S-S now any more than when I started writing this. My concern is that we already did 50% of this bulk adding job, and we are better off doing 100% or 0% rather than 50%. -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 27 16:32:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSg4u-0007lU-47; Wed, 27 Sep 2006 16:32:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSg4t-0007kN-En for ltru@ietf.org; Wed, 27 Sep 2006 16:32:23 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSg4s-0005p6-0w for ltru@ietf.org; Wed, 27 Sep 2006 16:32:23 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k8RKW80W043681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Sep 2006 13:32:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=QAPEUQKGBy8E3oDRMYWKNdBF9pn5rEAqjDauR76jzkN6ajSDkdul6UZlm1NMnFPC Message-ID: <451ADFC8.1030807@yahoo-inc.com> Date: Wed, 27 Sep 2006 13:32:08 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Doug Ewell References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <451ACCC5.6010609@yahoo-inc.com> <034701c6e271$c9fb9dd0$6401a8c0@DGBP7M81> In-Reply-To: <034701c6e271$c9fb9dd0$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: LTRU Working Group Subject: [Ltru] Re: Suppress-Script batch 1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, Some notes follow. Doug Ewell wrote: > Addison Phillips wrote: > >>> (Cross-posted to ietf-languages, since it really belongs there.) >> >> It does NOT belong there. I object in the strongest possible terms to >> my being cross-posted, especially in an edited form. > > OK, I apologize. I thought ietf-languages was where decisions were made > about specific items in the Registry, and LTRU was where the governing > documents and policy decisions about them were discussed. I guess this > fell on the policy side. No, my bad for being grouchy. > >> By contrast, determining which small number of languages are >> customarily written in more than one script (Note Well: the word >> 'customarily'!) is a far easier task. > > Even that carries the potential for controversy. Is Santali > "customarily" written in Ol Chiki? That probably depends on who you ask. Yes, but the demonstration for multiple scripts is relatively easier to prove: find some moderately large number of documents in each of the scripts. Presence of more than one script, plus, is possible, descriptions of the language as being written in more than one script is a *positive* demonstration of multiple scripts. Whereas, you can produce all the documents in Tatar in Cyrillic that you want: it doesn't prove that there are (or are not) a large number of Tatar documents lurking somewhere in the Latin script. Proving the negative case is hard without a Tatar library card. > >> It took a lot of work to arrive at that [Korean] conclusion, no? Why >> are these other languages different? > > They aren't, necessarily. Some might be less work, some more. This is > one reason I don't just starting ticking boxes when a list like John's > comes up, like I'm voting for an All-Star team. I don't personally have > the expertise to make most of those calls, and they should only be made > by those who do. Avoiding the necessity would seem like a better choice. The compatibility issues are avoided if we can make strong enough positive statements about not using script subtags except where they are necessary and providing for ways that registrants can create information showing the minority of cases where they are. > >> I've said enough. I think this an awful idea, but no one else seems to >> see the difficulties involved. So I'm going to quit raising my sour >> grapes up for general viewing. On the other hand, I note that attempts >> to create this informative field have already demonstrated some >> workability problems. > > S-S provides a long-term solution for a world that continues to use > remove-from-right prefix matching and unnecessary region subtags, > instead of using the recommendations in RFC 4647 which would solve all > of these problems. We assume that tag producers will start adding > script subtags indiscriminately, but that tag consumers will *not* > update their matching engines to understand them. Assumptions that may or may not be true. But the problem here is that S-S seeks to provide, at great cost and difficulty, mechanisms to address the problem which could be better solved through simpler, more manageable means. >> >> When they are proposed, you can count on my emitting a quiet -1 for >> each of them. Consensus, after all, is not unanimity. > > Would you support removing some of the ones that are there already? Yes. I support (one might infer) removing them *all* and adding another kind of field to solve the problem. The reason S-S was chosen was the impression that no one would ever read RFC 4646 (maybe not such a bad assumption) and just look at the registry. S-S provides a very positive hint to authors of "major" languages (i.e. those with 639-1 codes) not to start using the script subtag. I'd almost prefer limiting it to the alpha2 codes. > > I don't like S-S now any more than when I started writing this. My > concern is that we already did 50% of this bulk adding job, and we are > better off doing 100% or 0% rather than 50%. > 0% does less potential harm than 100% does ;-) Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 27 18:39:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSi4I-0004el-Tz; Wed, 27 Sep 2006 18:39:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSi4H-0004eC-AK for ltru@ietf.org; Wed, 27 Sep 2006 18:39:53 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSi4E-00040b-EA for ltru@ietf.org; Wed, 27 Sep 2006 18:39:53 -0400 Received: by nf-out-0910.google.com with SMTP id n15so627437nfc for ; Wed, 27 Sep 2006 15:39:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=uSS4yMVswKnzpqAIG91jTPkVVTaaYGfSzz8h1RZJ8KLoecLmV34oZMKpWbnqM6FvsW1zt3/A3us+ScRIbY+PeMyiYhOAo///Os6AWfCv5/zr3MyGir6lYaHS/CbwItDEkPmQf2MyEaspJ+pVKHOySNJFctaIFjCU7zHKEklX80M= Received: by 10.48.210.20 with SMTP id i20mr2963683nfg; Wed, 27 Sep 2006 15:39:49 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Wed, 27 Sep 2006 15:39:49 -0700 (PDT) Message-ID: <30b660a20609271539pac3aa26w70e7e447b5981a9e@mail.gmail.com> Date: Wed, 27 Sep 2006 15:39:49 -0700 From: "Mark Davis" To: "Frank Ellermann" In-Reply-To: <451A335A.56DC@xyzzy.claranet.de> MIME-Version: 1.0 References: <45193FC2.26E2@xyzzy.claranet.de> <20060926185837.GB20579@ccil.org> <451A335A.56DC@xyzzy.claranet.de> X-Google-Sender-Auth: 3ac827de81ef2a7f X-Spam-Score: 0.4 (/) X-Scan-Signature: 958aa603499a3de6b2b87d68741ed60e Cc: Michael Everson , LTRU Working Group , ietf-languages@alvestrand.no Subject: [Ltru] Re: frr, fy, ngo, tt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0330164355==" Errors-To: ltru-bounces@ietf.org --===============0330164355== Content-Type: multipart/alternative; boundary="----=_Part_10399_4659988.1159396789160" ------=_Part_10399_4659988.1159396789160 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SWYgeW91IGFyZSBnb2luZyB0byBkbyBhbnkgYW5hbHlzaXMgb2YgdGhlIGRpZmZlcmVuY2VzLCBw bGVhc2UgdGFrZSBhIGxvb2sKYWxzbyBhdCBteSBtZXNzYWdlIG9mCgpGcm9tOiAqTWFyayBEYXZp cyA8bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmc+Kk1haWxlZC1CeTogKmdtYWlsLmNvbSoKU3Vi amVjdDogKlJlOiBMYW5ndWFnZXMgYW5kIFNjcmlwdHMqCgp3aGljaCBjb250YWluZWQgYSBsaXN0 aW5nIG9mIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlIENMRFIgZGF0YSBhbmQgb3RoZXIKVW5pY29k ZSBkYXRhIHRoYXQgd2Ugd291bGQgbGlrZSB0byByZWNvbmNpbGUuIEkgcmVwZWF0IHRoZSBkYXRh IGJlbG93LgoKSW4gcGFydGljdWxhciwgSSBoYWQgYXNrZWQgb24gdGhpcyBsaXN0IGlmIGFueW9u ZSBrbmV3IGFueXRoaW5nIGFib3V0IHRoZQpjb3VwbGUgb2YgZG96ZW4gcHVycG9ydGVkIGxhbmd1 YWdlcyBhdCB0aGUgZW5kIGZvciB3aGljaCBNYWdkYSBjb3VsZG4ndCBmaW5kCjYzOS0zIGxhbmd1 YWdlIGNvZGVzLiBIZWFyaW5nIG5vIHJlc3BvbnNlLCB3ZSB3aWxsIHByb2JhYmx5IGp1c3QgcmVt b3ZlIHRoZW0KZnJvbSB0aGUgVW5pY29kZSBzaXRlIGFzIGJvZ3VzLgoKW2FicV0gOyBBYmF6YSA7 IFtDeXJsXSA7ClthZHldIDsgQWR5Z2VpIDsgICAgICAgIFtDeXJsXSA7ClthaW5dIDsgQWludSA7 ICBbS2FuYV07IFtMYXRuXSA7ClthbW9dIDsgQW1vIDsgICBbTGF0bl0gOwpbYXZdIDsgIEF2YXIg KEF2YXJpYz8pIDsgICAgICAgIFtDeXJsXSA7Clthd2FdIDsgQXdhZGhpIDsgICAgICAgIFtEZXZh XSA7CltiYV0gOyAgQmFzaGtpciA7ICAgICAgIFtDeXJsXSA7CltiYmNdIDsgQmF0YWsgdG9iYSA7 ICAgIFtCYXRrXSo7IFtMYXRuXSA7CltiZnFdIDsgQmFkYWdhIDsgICAgICAgIFtUYW1sXSA7Clti ZnRdIDsgQmFsdGkgOyBbRGV2YV0gOyAgICAgICAgW1JlbW92ZWQgQmFsdGldCltiZnldIDsgQmFn aGVsaSA7ICAgICAgIFtEZXZhXSA7CltiaF0gOyAgQmloYXJpIDsgICAgICAgIFtEZXZhXSA7Clti aGJdIDsgQmhpbGkgOyBbRGV2YV0gOwpbYmhvXSA7IEJob2pwdXJpIDsgICAgICBbRGV2YV0gOwpb YmpqXSA7IEthbmF1amkgOyAgICAgICBbRGV2YV0gOwpbYmt1XSA7IEJ1aGlkIDsgW0J1aGRdIDsK W2JyXSA7ICBCcmV0b24gOyAgICAgICAgW0xhdG5dIDsKW2JyYV0gOyBCcmFqIGJoYXNoYSA7ICAg W0RldmFdIDsKW2J0a10gOyBCYXRhayA7IFtCYXRrXSosIFtMYXRuXSA7CltidHZdIDsgQmF0ZXJp IChha2EgQmhhdG5lcmkpICA7ICAgICAgICBbRGV2YV0gOwpbY2NwXSA7IENoYWttYSA7ICAgICAg ICBbQmVuZ107IDsgICAgICAgW1JlbW92ZWQgQ2hha21hXQpbY2VdIDsgIENoZWNoZW4gOyAgICAg ICBbQ3lybF0gOwpbY2htXSA7IE1hcmkgOyAgW0N5cmxdOyBbTGF0bl0gOwpbY2pzXSA7IFNob3Ig OyAgW0N5cmxdIDsKW2NvXSA7ICBDb3JzaWNhbiA7ICAgICAgW0xhdG5dIDsKW2NvcF0gOyBDb3B0 aWMgOyAgICAgICAgW0FyYWJdOyBbQ29wdF0gOyAgICAgICAgIltBZGRlZCBHcmVrLCBidXQgaXMg dGhhdApyaWdodCBub3c/XSIKW2NyXSA7ICBDcmVlIDsgIFtDYW5zXTsgW0xhdG5dIDsKW2N2XSA7 ICBDaHV2YXNoIDsgICAgICAgW0N5cmxdIDsKW2Rhcl0gOyBEYXJnd2EgOyAgICAgICAgW0N5cmxd IDsKW2VuXSA7ICBFbmdsaXNoIDsgICAgICAgW0xhdG5dIDsgICAgICAgICJbSGFkIFNoYXZpYW4g YW5kIERlc2VyZXQsIGJ1dCB0aG9zZQpuZXZlcgpoYWQgYW55IHNpZ25pZmljYW50IHVzYWdlXSIK W2V2bl0gOyBFdmVua2kgOyAgICAgICAgW0N5cmxdIDsKW2dhZ10gOyBHYWdhdXogOyAgICAgICAg W0N5cmxdIDsKW2dibV0gOyBHYXJod2FsaSA7ICAgICAgW0RldmFdCltnZF0gOyAgR2FlbGljIDsg ICAgICAgIFtMYXRuXQpbZ2xkXSA7IE5hbmFpIDsgW0N5cmxdCltnb25dIDsgR29uZGkgOyBbRGV2 YV07IFtUZWx1XQpbZ3J0XSA7IEdhcm8gOyAgW0JlbmddCltobW5dIDsgSG1vbmcgOyBbTGF0bl07 IFtIbW5nXSoKW2hubl0gOyBIYW51bsOzbyA7ICAgICAgIFtMYXRuXTsgW0hhbm9dCltob2NdIDsg SG8gOyAgICBbRGV2YV0KW2hval0gOyBIYXJhdXRpIDsgICAgICAgW0RldmFdCltob3BdIDsgSG9w aSA7ICBbTGF0bl0KW2h5XSA7ICBBcm1lbmlhbiA7ICAgICAgW0FybW5dOyBbU3lyY10qCltpYmJd IDsgSWJpYmlvIDsgICAgICAgIFtMYXRuXQpbaWRdIDsgIEluZG9uZXNpYW4gOyAgICAiW0FyYWJd KiwgW0xhdG5dIgpbaWtdIDsgIEnDsXVwaWFxIDsgICAgICAgW0xhdG5dCltpbmhdIDsgSW5ndXNo IDsgICAgICAgIFtBcmFiXTsgW0xhdG5dCltqdl0gOyAgSmF2YW5lc2UgOyAgICAgIFtMYXRuXTsg W0phdmFdKgpba2FhXSA7IEthcmFrYWxwYWsgOyAgICBbQ3lybF0KW2thY10/IDsgICAgICAgIEth Y2hjaGkgOyAgICAgICBbRGV2YV0KW2tiZF0gOyBLYWJhcmRpYW4gOyAgICAgW0N5cmxdCltrY2Fd IDsgS2hhbnR5IDsgICAgICAgIFtDeXJsXQpba2R0XSA7IEt1eSA7ICAgVGhhaQpba2hhXSA7IEto YXNpIDsgW0xhdG5dOyBbQmVuZ10KW2todF0gOyBLaGFtdGkgOyAgICAgICAgW015bXJdCltrcl0g OyAgS2FudXJpIDsgICAgICAgIFtMYXRuXQpba3JjXSA7IEthcmFjaGF5IDsgICAgICBbQ3lybF0K W2tybF0gOyBLYXJlbGlhbiA7ICAgICAgW0xhdG5dOyBbQ3lybF0KW2t2XSA7ICBLb21pIDsgIFtD eXJsXTsgW0xhdG5dCltreV0gOyAgS2lyZ2hpeiA7ICAgICAgIFtBcmFiXSo7IFtMYXRuXTsgW0N5 cmxdCltsYWRdIDsgTGFkaW5vIDsgICAgICAgIFtIZWJyXQpbbGJlXSA7IExhayA7ICAgW0N5cmxd CltsY3BdIDsgIkxhd2EsIHdlc3Rlcm4iIDsgICAgICAgVGhhaQpbbGVwXSA7IExlcGNoYSA7ICAg ICAgICBbTGVwY10qCltsZXpdIDsgTGV6Z2hpYW4gKExlemdoaT8pIDsgICAgW0N5cmxdCltsaV0/ IDsgTGltYnUgOyBbRGV2YV07IFtMaW1iXQpbbGlzXSA7IExpc3UgOyAgIkxpc3UgKEZyYXNlcikq LCBbTGF0bl0iCltsbW5dIDsgTGFtYmFkaSA7ICAgICAgIFtUZWx1XQpbbHV0XSA7IEx1c2hvb3Rz ZWVkIDsgICBbTGF0bl0KW2x3bF0gOyAiTGF3YSwgZWFzdGVybiIgOyAgICAgICBUaGFpClttbmNd IDsgTWFuY2h1IDsgICAgICAgIFtNb25nXQpbbW5pXSA7IE1laXRlaSA7ICAgICAgICAiTWVldGFp IE1heWVrKiwgW0JlbmddIgpbbW5zXSA7IE1hbnNpIDsgW0N5cmxdClttbnddIDsgTW9uIDsgICBb TXltcl0KW211d10gOyBNdW5kYXJpIDsgICAgICAgW0JlbmddOyBbRGV2YV0KW213cl0gOyBNYXJ3 YXJpIDsgICAgICAgW0RldmFdCltuYmZdIDsgTmF4aSA7ICBOYXhpKgpbbmV3XSA7IE5ld2FyaSA7 ICAgICAgICAiW0RldmFdOyBSYW5qYW5hLCBQYXJhY2hhbGl0Igpbbm9nXSA7IE5vZ2FpIDsgW0N5 cmxdCltudl0gOyAgTmF2YWpvIDsgICAgICAgIFtMYXRuXQpbb21dIDsgIE9yb21vIDsgW0V0aGld KjsgW0xhdG5dIDsgICAgICAgIltBY2NvcmRpbmcgdG8gd2lraXBlZGlhLCBFdGhpIHVzYWdlCmlz IG9sZCIKW29zXSA7ICBPc3NldGljIDsgICAgICAgW0N5cmxdOyBbTGF0bl0gOwpbcGldIDsgIFBh bGkgOyAgW1NpbmhdOyBbRGV2YV07IFtUaGFpXSA7CltwcmRdIDsgUGFyc2ktZGFyaSA7ICAgIFtB cmFiXSA7CltwcmddIDsgUHJ1c3NpYW4gOyAgICAgIFtMYXRuXSA7Cltyb10gOyAgUm9tYW5pYW4g OyAgICAgIFtMYXRuXTsgW0N5cmxdKiA7Cltyb21dIDsgUm9tYW55IDsgICAgICAgIFtDeXJsXTsg W0xhdG5dIDsKW3NhXSA7ICBTYW5za3JpdCA7ICAgICAgW1NpbmhdOyBbRGV2YV07IGV0Yy4gOyAg W0NMRFIgZG9lc24ndCBkbyAnZXRjJzogd2hhdAppcyB0aGUgZXhhY3QgbGlzdDogYWxsIG1vZGVy biBJbmRpYyBzY3JpcHRzICsgU2luaGFsYT9dCltzYWhdIDsgWWFrdXQgOyBbQ3lybF0gOwpbc2F0 XSA7IFNhbnRhbGkgOyAgICAgICBbRGV2YV07IFtCZW5nXTsgW09yeWFdOyBbT2xja10qIDsKW3Nl bF0gOyBTZWxrdXAgOyAgICAgICAgW0N5cmxdIDsKW3Nobl0gOyBTaGFuIDsgIFtNeW1yXSA7Cltz bWldIDsgU2FtaSA7ICBbQ3lybF07IFtMYXRuXSA7ICAgICAgICBbSXMgQ3lybCBjb21tb24/XQpb c21wXSA7IFNhbWFyaXRhbiA7ICAgICBbSGVicl0gOyAgICAgICAgW1JlbW92ZWQgU2FtYXJpdGFu Kgpbc25dIDsgIFNob25hIDsgW0xhdG5dIDsKW3N5bF0gOyBTeWxoZXR0aSA7ICAgICAgW1N5bG9d OyBbQmVuZ10gOwpbdGFiXSA7IFRhYmFzYXJhbiA7ICAgICBbQ3lybF0gOwpbdGJ3XSA7IFRhZ2Jh bndhIDsgICAgICBbTGF0bl07ICA7ICAgICAgW1JlbW92ZWQgVGFnYmFud2FdClt0Y3ldIDsgVHVs dSA7ICBbS25kYV0gOwpbdGxdIDsgIFRhZ2Fsb2cgOyAgICAgICBbTGF0bl07IFtUZ2xnXSA7ICAg ICAgICBbSXQgYXBwZWFycyB0aGF0IFRnbGcgaXMgbm90CmluIG1vZGVybiB1c2VdClt0cnVdIDsg VHVyb3lvIDsgICAgICAgIFtTeXJjXSA7Clt0dHRdIDsgVGF0IDsgICBbQ3lybF0gOwpbdHV0XSA7 IEFsdGFpIChBbHRhaWM/KSA7ICAgICAgIFtDeXJsXSA7Clt0eV0gOyAgVGFoaXRpYW4gOyAgICAg IFtMYXRuXSA7Clt1ZG1dIDsgVWRtdXJ0IDsgICAgICAgIFtDeXJsXTsgW0xhdG5dIDsKW3VnXSA7 ICBVaWdodXIgOyAgICAgICAgW0FyYWJdOyBbTGF0bl07IFtDeXJsXSA7ICAgICAgICAiW2FkZHMg TGF0biwgQ3lybDsKaXMgdGhlCmxhdHRlciBjb21tb24/ICBSZW1vdmVkIFVpZ2h1cl0iClt2aV0g OyAgVmlldG5hbWVzZSA7ICAgIFtMYXRuXTsgQ2h1IE5vbSA7ICAgICAgIFtDaHUgTm9tIHdvdWxk IGJlIEhhbmkqXQpbeGFsXSA7IEthbG15ayA7ICAgICAgICBbQ3lybF0gOwpbeHNyXSA7IFNoZXJw YSA7ICAgICAgICBbRGV2YV0gOwpbeXJrXSA7IE5lbmV0cyA7ICAgICAgICBbQ3lybF0gOwoKIyBN aXNzaW5nIExhbmd1YWdlIENvZGVzCgo/Pz8gOyAgIEFpc29yIDsgW0N5cmxdCj8/PyA7ICAgQXNz eXJpYW4gKG1vZGVybikgOyAgICAgW1N5cmNdCj8/PyA7ICAgQmFoYXNhIDsgICAgICAgIFtMYXRu XQo/Pz8gOyAgIEJhbGVhciA7ICAgICAgICBbTGF0bl0KPz8/IDsgICBCYWxrYXIgOyAgICAgICAg W0N5cmxdCj8/PyA7ICAgQnVnaXMgOyBbQnVnaV0KPz8/IDsgICBCdXJ5YXQgOyAgICAgICAgW0N5 cmxdCj8/PyA7ICAgQ2hhbSA7ICBbQ2hhbV0qCj8/PyA7ICAgQ2hoYXR0aXNnYXJoaSA7IFtEZXZh XQo/Pz8gOyAgIENodWtjaGkgOyAgICAgICBbQ3lybF0KPz8/IDsgICBEdW5nYW4gOyAgICAgICAg W0N5cmxdCj8/PyA7ICAgRWRvIDsgICBbTGF0bl0KPz8/IDsgICBHYXJzaHVuaSA7ICAgICAgW1N5 cmNdCj8/PyA7ICAgR2FzY29uIDsgICAgICAgIFtMYXRuXQo/Pz8gOyAgIEp1ZGV6bW8gOyAgICAg ICBbSGVicl0KPz8/IDsgICBLYW5rYW4gOyAgICAgICAgW0RldmFdCj8/PyA7ICAgS2hha2FzcyA7 ICAgICAgIFtDeXJsXQo/Pz8gOyAgIEtvcnlhayA7ICAgICAgICBbQ3lybF0KPz8/IDsgICBMYXBw IDsgIFtMYXRuXQo/Pz8gOyAgIE1vcmR2aW4gOyAgICAgICBbQ3lybF0KPz8/IDsgICBOYWdhIDsg IFtMYXRuXTsgW0JlbmddCj8/PyA7ICAgUmlhbmcgOyBbQmVuZ10KPz8/IDsgICBTd2FkYXlhIDsg ICAgICAgW1N5cmNdCj8/PyA7ICAgVGFtYXppZ2h0IDsgICAgIFtUZm5nXSwgW0xhdG5dCj8/PyA7 ICAgVHNhbGFnaSA7ICAgICAgIChzZWUgQ2hlcm9rZWUpCj8/PyA7ICAgVHV2YSA7ICBbQ3lybF0K Pz8/IDsgICBVZGVraGUgOyAgICAgICAgW0N5cmxdCgpPbiA5LzI3LzA2LCBGcmFuayBFbGxlcm1h bm4gPG5vYm9keUB4eXp6eS5jbGFyYW5ldC5kZT4gd3JvdGU6Cj4KPiBKb2huIENvd2FuIHdyb3Rl Ogo+Cj4gPiBJJ2xsIHBvc3QgKHNvbWUgb2YpIHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoaW5ncyBz aG9ydGx5Lgo+Cj4gSGVyZSdzIGEgbGlzdCBvZiA2NyBkaWZmZXJlbmNlcyBiZXR3ZWVuIExUUlUg YW5kIENMRFIgMS40Cj4KPiBMaW5lcyB3aGVyZSBMVFJVIGhhcyBubyBzY3JpcHQgYW5kIENMRFIg bW9yZSB0aGFuIG9uZSBhcmUKPiBtb3N0IHByb2JhYmx5IHNhbmUsIGJ1dCBhbnl0aGluZyBlbHNl IHNob3VsZCBiZSBjaGVja2VkOgo+Cj4gbGFuZyBhYSAgbHRydSAgICAgIGNsZHIgTGF0bgo+IGxh bmcgYWsgIGx0cnUgICAgICBjbGRyIExhdG4KPiBsYW5nIGF6ICBsdHJ1ICAgICAgY2xkciBBcmFi IEN5cmwgTGF0bgo+IGxhbmcgYm8gIGx0cnUgICAgICBjbGRyIFRpYnQKPiBsYW5nIGNyICBsdHJ1 ICAgICAgY2xkciBDYW5zIExhdG4KPiBsYW5nIGVlICBsdHJ1ICAgICAgY2xkciBMYXRuCj4gbGFu ZyBmeSAgbHRydSAgICAgIGNsZHIgTGF0bgo+IGxhbmcgZ2QgIGx0cnUgICAgICBjbGRyIExhdG4K PiBsYW5nIGhhICBsdHJ1ICAgICAgY2xkciBBcmFiIExhdG4KPiBsYW5nIGhvICBsdHJ1ICAgICAg Y2xkciBMYXRuCj4gbGFuZyBpYSAgbHRydSAgICAgIGNsZHIgTGF0bgo+IGxhbmcgaWcgIGx0cnUg ICAgICBjbGRyIExhdG4KPiBsYW5nIGl1ICBsdHJ1ICAgICAgY2xkciBDYW5zIEN5cmwgTGF0bgo+ IGxhbmcgamEgIGx0cnUgICAgICBjbGRyIEhhbmkgSGlyYSBLYW5hCj4gbGFuZyBrbyAgbHRydSAg ICAgIGNsZHIgSGFuZyBIYW5pCj4gbGFuZyBrcyAgbHRydSAgICAgIGNsZHIgQXJhYiBEZXZhCj4g bGFuZyBrdSAgbHRydSAgICAgIGNsZHIgQXJhYiBDeXJsIExhdG4KPiBsYW5nIGt3ICBsdHJ1ICAg ICAgY2xkciBMYXRuCj4gbGFuZyBreSAgbHRydSAgICAgIGNsZHIgQXJhYiBDeXJsCj4gbGFuZyBt aSAgbHRydSAgICAgIGNsZHIgTGF0bgo+IGxhbmcgbW4gIGx0cnUgICAgICBjbGRyIEN5cmwgTW9u Zwo+IGxhbmcgbW8gIGx0cnUgTGF0biBjbGRyIEN5cmwgTGF0bgo+IGxhbmcgbXMgIGx0cnUgTGF0 biBjbGRyIEFyYWIgTGF0bgo+IGxhbmcgb2MgIGx0cnUgICAgICBjbGRyIExhdG4KPiBsYW5nIG9z ICBsdHJ1ICAgICAgY2xkciBMYXRuCj4gbGFuZyBwYSAgbHRydSBHdXJ1IGNsZHIgQXJhYiBHdXJ1 Cj4gbGFuZyBybSAgbHRydSAgICAgIGNsZHIgTGF0bgo+IGxhbmcgc2EgIGx0cnUgICAgICBjbGRy IERldmEKPiBsYW5nIHNkICBsdHJ1ICAgICAgY2xkciBBcmFiIERldmEKPiBsYW5nIHNlICBsdHJ1 ICAgICAgY2xkciBMYXRuCj4gbGFuZyBzaCAgbHRydSAgICAgIGNsZHIgTGF0bgo+IGxhbmcgc3Ig IGx0cnUgICAgICBjbGRyIEN5cmwgTGF0bgo+IGxhbmcgdGcgIGx0cnUgICAgICBjbGRyIEFyYWIg Q3lybCBMYXRuCj4gbGFuZyB0ayAgbHRydSAgICAgIGNsZHIgQXJhYiBDeXJsIExhdG4KPiBsYW5n IHRyICBsdHJ1IExhdG4gY2xkciBBcmFiIExhdG4KPiBsYW5nIHR0ICBsdHJ1ICAgICAgY2xkciBD eXJsCj4gbGFuZyB1ZyAgbHRydSAgICAgIGNsZHIgQXJhYgo+IGxhbmcgdXogIGx0cnUgICAgICBj bGRyIEFyYWIgQ3lybCBMYXRuCj4gbGFuZyB5byAgbHRydSAgICAgIGNsZHIgTGF0bgo+IGxhbmcg emggIGx0cnUgICAgICBjbGRyIEJvcG8gSGFuaSBIYW5zIEhhbnQKPiBsYW5nIGJhbCBsdHJ1ICAg ICAgY2xkciBBcmFiIExhdG4KPiBsYW5nIGJ5biBsdHJ1ICAgICAgY2xkciBFdGhpCj4gbGFuZyBj Y2ggbHRydSAgICAgIGNsZHIgTGF0bgo+IGxhbmcgY2hyIGx0cnUgICAgICBjbGRyIENoZXIgTGF0 bgo+IGxhbmcgY29wIGx0cnUgICAgICBjbGRyIEFyYWIgQ29wdAo+IGxhbmcgZmlsIGx0cnUgICAg ICBjbGRyIExhdG4KPiBsYW5nIGZpdSBsdHJ1ICAgICAgY2xkciBMYXRuCj4gbGFuZyBmdXIgbHRy dSAgICAgIGNsZHIgTGF0bgo+IGxhbmcgZ2FhIGx0cnUgICAgICBjbGRyIExhdG4KPiBsYW5nIGdl eiBsdHJ1ICAgICAgY2xkciBFdGhpCj4gbGFuZyBnc3cgbHRydSAgICAgIGNsZHIgTGF0bgo+IGxh bmcgaGF3IGx0cnUgICAgICBjbGRyIExhdG4KPiBsYW5nIGthaiBsdHJ1ICAgICAgY2xkciBMYXRu Cj4gbGFuZyBrYW0gbHRydSAgICAgIGNsZHIgTGF0bgo+IGxhbmcga2NnIGx0cnUgICAgICBjbGRy IExhdG4KPiBsYW5nIGtmbyBsdHJ1ICAgICAgY2xkciBMYXRuCj4gbGFuZyBrcGUgbHRydSAgICAg IGNsZHIgTGF0bgo+IGxhbmcgc2lkIGx0cnUgICAgICBjbGRyIExhdG4KPiBsYW5nIHNtYSBsdHJ1 ICAgICAgY2xkciBMYXRuCj4gbGFuZyBzbWkgbHRydSAgICAgIGNsZHIgTGF0bgo+IGxhbmcgc21q IGx0cnUgICAgICBjbGRyIExhdG4KPiBsYW5nIHNtbiBsdHJ1ICAgICAgY2xkciBMYXRuCj4gbGFu ZyBzbXMgbHRydSAgICAgIGNsZHIgTGF0bgo+IGxhbmcgc3lyIGx0cnUgICAgICBjbGRyIFN5cmMK PiBsYW5nIHRldCBsdHJ1ICAgICAgY2xkciBMYXRuCj4gbGFuZyB0aWcgbHRydSAgICAgIGNsZHIg RXRoaQo+IGxhbmcgd2FsIGx0cnUgICAgICBjbGRyIEV0aGkKPgo+Cj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBJZXRmLWxhbmd1YWdlcyBtYWlsaW5n IGxpc3QKPiBJZXRmLWxhbmd1YWdlc0BhbHZlc3RyYW5kLm5vCj4gaHR0cDovL3d3dy5hbHZlc3Ry YW5kLm5vL21haWxtYW4vbGlzdGluZm8vaWV0Zi1sYW5ndWFnZXMKPgo= ------=_Part_10399_4659988.1159396789160 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SWYgeW91IGFyZSBnb2luZyB0byBkbyBhbnkgYW5hbHlzaXMgb2YgdGhlIGRpZmZlcmVuY2VzLCBw bGVhc2UgdGFrZSBhIGxvb2sgYWxzbyBhdCBteSBtZXNzYWdlIG9mIDxicj48YnI+PHRhYmxlIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgd2lkdGg9IjEwMCUiPjx0Ym9keT48dHI+PHRk IHN0eWxlPSJmb250LXNpemU6IDgwJTsgdGV4dC1pbmRlbnQ6IDRweDsiIG5vd3JhcD0ibm93cmFw Ij4KRnJvbTogPGIgaWQ9Il91c2VyX21hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnIj5NYXJrIERh dmlzICZsdDs8YSBocmVmPSJtYWlsdG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmciPm1hcmsu ZGF2aXNAaWN1LXByb2plY3Qub3JnPC9hPiZndDs8L2I+PC90ZD48dGQgc3R5bGU9ImZvbnQtc2l6 ZTogNjUlOyIgYWxpZ249InJpZ2h0IiBub3dyYXA9Im5vd3JhcCI+TWFpbGVkLUJ5OiA8Yj4KPGEg aHJlZj0iaHR0cDovL2dtYWlsLmNvbSI+Z21haWwuY29tPC9hPjwvYj48L3RkPjwvdHI+PC90Ym9k eT48L3RhYmxlPjxicj48ZGl2IGNsYXNzPSJtaGwiPlN1YmplY3Q6IDxiPlJlOiBMYW5ndWFnZXMg YW5kIFNjcmlwdHM8L2I+PC9kaXY+PGJyPndoaWNoIGNvbnRhaW5lZCBhIGxpc3Rpbmcgb2YgZGlm ZmVyZW5jZXMgYmV0d2VlbiB0aGUgQ0xEUiBkYXRhIGFuZCBvdGhlciBVbmljb2RlIGRhdGEgdGhh dCB3ZSB3b3VsZCBsaWtlIHRvIHJlY29uY2lsZS4gSSByZXBlYXQgdGhlIGRhdGEgYmVsb3cuCjxi cj48YnI+SW4gcGFydGljdWxhciwgSSBoYWQgYXNrZWQgb24gdGhpcyBsaXN0IGlmIGFueW9uZSBr bmV3IGFueXRoaW5nIGFib3V0IHRoZSBjb3VwbGUgb2YgZG96ZW4gcHVycG9ydGVkIGxhbmd1YWdl cyBhdCB0aGUgZW5kIGZvciB3aGljaCBNYWdkYSBjb3VsZG4ndCBmaW5kIDYzOS0zIGxhbmd1YWdl IGNvZGVzLiBIZWFyaW5nIG5vIHJlc3BvbnNlLCB3ZSB3aWxsIHByb2JhYmx5IGp1c3QgcmVtb3Zl IHRoZW0gZnJvbSB0aGUgVW5pY29kZSBzaXRlIGFzIGJvZ3VzLgo8YnI+PGJyPlthYnFdIDsgQWJh emEgOyBbQ3lybF0gOzxicj5bYWR5XSA7IEFkeWdlaSA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO1tDeXJsXSA7PGJyPlthaW5dIDsgQWludSA7ICZuYnNwO1tLYW5hXTsgW0xhdG5dIDs8YnI+ W2Ftb10gOyBBbW8gOyAmbmJzcDsgW0xhdG5dIDs8YnI+W2F2XSA7ICZuYnNwO0F2YXIgKEF2YXJp Yz8pIDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W0N5cmxdIDs8YnI+W2F3YV0gOyBBd2Fk aGkgOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbRGV2YV0gOzxicj5bYmFdIDsgJm5ic3A7 QmFzaGtpciA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtDeXJsXSA7Cjxicj5bYmJjXSA7IEJhdGFr IHRvYmEgOyAmbmJzcDsgJm5ic3A7W0JhdGtdKjsgW0xhdG5dIDs8YnI+W2JmcV0gOyBCYWRhZ2Eg OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbVGFtbF0gOzxicj5bYmZ0XSA7IEJhbHRpIDsg W0RldmFdIDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W1JlbW92ZWQgQmFsdGldPGJyPlti ZnldIDsgQmFnaGVsaSA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtEZXZhXSA7PGJyPltiaF0gOyAm bmJzcDtCaWhhcmkgOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbRGV2YV0gOzxicj5bYmhi XSA7IEJoaWxpIDsgW0RldmFdIDsKPGJyPltiaG9dIDsgQmhvanB1cmkgOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1tEZXZhXSA7PGJyPltiampdIDsgS2FuYXVqaSA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFtEZXZhXSA7PGJyPltia3VdIDsgQnVoaWQgOyBbQnVoZF0gOzxicj5bYnJdIDsgJm5ic3A7QnJl dG9uIDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W0xhdG5dIDs8YnI+W2JyYV0gOyBCcmFq IGJoYXNoYSA7ICZuYnNwOyBbRGV2YV0gOzxicj5bYnRrXSA7IEJhdGFrIDsgW0JhdGtdKiwgW0xh dG5dIDs8YnI+W2J0dl0gOyBCYXRlcmkgKGFrYSBCaGF0bmVyaSkgJm5ic3A7OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtbRGV2YV0gOwo8YnI+W2NjcF0gOyBDaGFrbWEgOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtbQmVuZ107IDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgW1JlbW92ZWQg Q2hha21hXTxicj5bY2VdIDsgJm5ic3A7Q2hlY2hlbiA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtD eXJsXSA7PGJyPltjaG1dIDsgTWFyaSA7ICZuYnNwO1tDeXJsXTsgW0xhdG5dIDs8YnI+W2Nqc10g OyBTaG9yIDsgJm5ic3A7W0N5cmxdIDs8YnI+W2NvXSA7ICZuYnNwO0NvcnNpY2FuIDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtbTGF0bl0gOzxicj5bY29wXSA7IENvcHRpYyA7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO1tBcmFiXTsgW0NvcHRdIDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 JnF1b3Q7W0FkZGVkIEdyZWssIGJ1dCBpcyB0aGF0IHJpZ2h0IG5vdz9dJnF1b3Q7Cjxicj5bY3Jd IDsgJm5ic3A7Q3JlZSA7ICZuYnNwO1tDYW5zXTsgW0xhdG5dIDs8YnI+W2N2XSA7ICZuYnNwO0No dXZhc2ggOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBbQ3lybF0gOzxicj5bZGFyXSA7IERhcmd3YSA7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tDeXJsXSA7PGJyPltlbl0gOyAmbmJzcDtFbmds aXNoIDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgW0xhdG5dIDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7JnF1b3Q7W0hhZCBTaGF2aWFuIGFuZCBEZXNlcmV0LCBidXQgdGhvc2UgbmV2ZXI8YnI+ aGFkIGFueSBzaWduaWZpY2FudCB1c2FnZV0mcXVvdDsKPGJyPltldm5dIDsgRXZlbmtpIDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W0N5cmxdIDs8YnI+W2dhZ10gOyBHYWdhdXogOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbQ3lybF0gOzxicj5bZ2JtXSA7IEdhcmh3YWxpIDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtbRGV2YV08YnI+W2dkXSA7ICZuYnNwO0dhZWxpYyA7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO1tMYXRuXTxicj5bZ2xkXSA7IE5hbmFpIDsgW0N5cmxdPGJyPltn b25dIDsgR29uZGkgOyBbRGV2YV07IFtUZWx1XTxicj5bZ3J0XSA7IEdhcm8gOyAmbmJzcDtbQmVu Z10KPGJyPltobW5dIDsgSG1vbmcgOyBbTGF0bl07IFtIbW5nXSo8YnI+W2hubl0gOyBIYW51bsOz byA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtMYXRuXTsgW0hhbm9dPGJyPltob2NdIDsgSG8gOyAm bmJzcDsgJm5ic3A7W0RldmFdPGJyPltob2pdIDsgSGFyYXV0aSA7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IFtEZXZhXTxicj5baG9wXSA7IEhvcGkgOyAmbmJzcDtbTGF0bl08YnI+W2h5XSA7ICZuYnNw O0FybWVuaWFuIDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbQXJtbl07IFtTeXJjXSo8YnI+W2liYl0g OyBJYmliaW8gOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbTGF0bl0KPGJyPltpZF0gOyAm bmJzcDtJbmRvbmVzaWFuIDsgJm5ic3A7ICZuYnNwOyZxdW90O1tBcmFiXSosIFtMYXRuXSZxdW90 Ozxicj5baWtdIDsgJm5ic3A7ScOxdXBpYXEgOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBbTGF0bl08 YnI+W2luaF0gOyBJbmd1c2ggOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbQXJhYl07IFtM YXRuXTxicj5banZdIDsgJm5ic3A7SmF2YW5lc2UgOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tMYXRu XTsgW0phdmFdKjxicj5ba2FhXSA7IEthcmFrYWxwYWsgOyAmbmJzcDsgJm5ic3A7W0N5cmxdPGJy PltrYWNdPyA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0thY2hjaGkgOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBbRGV2YV0KPGJyPltrYmRdIDsgS2FiYXJkaWFuIDsgJm5ic3A7ICZuYnNwOyBb Q3lybF08YnI+W2tjYV0gOyBLaGFudHkgOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbQ3ly bF08YnI+W2tkdF0gOyBLdXkgOyAmbmJzcDsgVGhhaTxicj5ba2hhXSA7IEtoYXNpIDsgW0xhdG5d OyBbQmVuZ108YnI+W2todF0gOyBLaGFtdGkgOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtb TXltcl08YnI+W2tyXSA7ICZuYnNwO0thbnVyaSA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O1tMYXRuXTxicj5ba3JjXSA7IEthcmFjaGF5IDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbQ3lybF0K PGJyPltrcmxdIDsgS2FyZWxpYW4gOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tMYXRuXTsgW0N5cmxd PGJyPltrdl0gOyAmbmJzcDtLb21pIDsgJm5ic3A7W0N5cmxdOyBbTGF0bl08YnI+W2t5XSA7ICZu YnNwO0tpcmdoaXogOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBbQXJhYl0qOyBbTGF0bl07IFtDeXJs XTxicj5bbGFkXSA7IExhZGlubyA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tIZWJyXTxi cj5bbGJlXSA7IExhayA7ICZuYnNwOyBbQ3lybF08YnI+W2xjcF0gOyAmcXVvdDtMYXdhLCB3ZXN0 ZXJuJnF1b3Q7IDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhhaQo8YnI+W2xlcF0gOyBMZXBjaGEg OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbTGVwY10qPGJyPltsZXpdIDsgTGV6Z2hpYW4g KExlemdoaT8pIDsgJm5ic3A7ICZuYnNwO1tDeXJsXTxicj5bbGldPyA7IExpbWJ1IDsgW0RldmFd OyBbTGltYl08YnI+W2xpc10gOyBMaXN1IDsgJm5ic3A7JnF1b3Q7TGlzdSAoRnJhc2VyKSosIFtM YXRuXSZxdW90Ozxicj5bbG1uXSA7IExhbWJhZGkgOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBbVGVs dV08YnI+W2x1dF0gOyBMdXNob290c2VlZCA7ICZuYnNwOyBbTGF0bl0KPGJyPltsd2xdIDsgJnF1 b3Q7TGF3YSwgZWFzdGVybiZxdW90OyA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoYWk8YnI+W21u Y10gOyBNYW5jaHUgOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbTW9uZ108YnI+W21uaV0g OyBNZWl0ZWkgOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtNZWV0YWkgTWF5ZWsq LCBbQmVuZ10mcXVvdDs8YnI+W21uc10gOyBNYW5zaSA7IFtDeXJsXTxicj5bbW53XSA7IE1vbiA7 ICZuYnNwOyBbTXltcl08YnI+W211d10gOyBNdW5kYXJpIDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg W0JlbmddOyBbRGV2YV0KPGJyPlttd3JdIDsgTWFyd2FyaSA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFtEZXZhXTxicj5bbmJmXSA7IE5heGkgOyAmbmJzcDtOYXhpKjxicj5bbmV3XSA7IE5ld2FyaSA7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O1tEZXZhXTsgUmFuamFuYSwgUGFyYWNo YWxpdCZxdW90Ozxicj5bbm9nXSA7IE5vZ2FpIDsgW0N5cmxdPGJyPltudl0gOyAmbmJzcDtOYXZh am8gOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbTGF0bl08YnI+W29tXSA7ICZuYnNwO09y b21vIDsgW0V0aGldKjsgW0xhdG5dIDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7W0FjY29y ZGluZyB0byB3aWtpcGVkaWEsIEV0aGkgdXNhZ2UgaXMgb2xkJnF1b3Q7Cjxicj5bb3NdIDsgJm5i c3A7T3NzZXRpYyA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtDeXJsXTsgW0xhdG5dIDs8YnI+W3Bp XSA7ICZuYnNwO1BhbGkgOyAmbmJzcDtbU2luaF07IFtEZXZhXTsgW1RoYWldIDs8YnI+W3ByZF0g OyBQYXJzaS1kYXJpIDsgJm5ic3A7ICZuYnNwO1tBcmFiXSA7PGJyPltwcmddIDsgUHJ1c3NpYW4g OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tMYXRuXSA7PGJyPltyb10gOyAmbmJzcDtSb21hbmlhbiA7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7W0xhdG5dOyBbQ3lybF0qIDs8YnI+W3JvbV0gOyBSb21hbnkg OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbQ3lybF07IFtMYXRuXSA7Cjxicj5bc2FdIDsg Jm5ic3A7U2Fuc2tyaXQgOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tTaW5oXTsgW0RldmFdOyBldGMu IDsgJm5ic3A7W0NMRFIgZG9lc24ndCBkbyAnZXRjJzogd2hhdDxicj5pcyB0aGUgZXhhY3QgbGlz dDogYWxsIG1vZGVybiBJbmRpYyBzY3JpcHRzICsgU2luaGFsYT9dPGJyPltzYWhdIDsgWWFrdXQg OyBbQ3lybF0gOzxicj5bc2F0XSA7IFNhbnRhbGkgOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBbRGV2 YV07IFtCZW5nXTsgW09yeWFdOyBbT2xja10qIDsKPGJyPltzZWxdIDsgU2Vsa3VwIDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7W0N5cmxdIDs8YnI+W3Nobl0gOyBTaGFuIDsgJm5ic3A7W015 bXJdIDs8YnI+W3NtaV0gOyBTYW1pIDsgJm5ic3A7W0N5cmxdOyBbTGF0bl0gOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtbSXMgQ3lybCBjb21tb24/XTxicj5bc21wXSA7IFNhbWFyaXRhbiA7 ICZuYnNwOyAmbmJzcDsgW0hlYnJdIDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W1JlbW92 ZWQgU2FtYXJpdGFuKjxicj5bc25dIDsgJm5ic3A7U2hvbmEgOyBbTGF0bl0gOzxicj5bc3lsXSA7 IFN5bGhldHRpIDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbU3lsb107IFtCZW5nXSA7Cjxicj5bdGFi XSA7IFRhYmFzYXJhbiA7ICZuYnNwOyAmbmJzcDsgW0N5cmxdIDs8YnI+W3Rid10gOyBUYWdiYW53 YSA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W0xhdG5dOyAmbmJzcDs7ICZuYnNwOyAmbmJzcDsgJm5i c3A7W1JlbW92ZWQgVGFnYmFud2FdPGJyPlt0Y3ldIDsgVHVsdSA7ICZuYnNwO1tLbmRhXSA7PGJy Plt0bF0gOyAmbmJzcDtUYWdhbG9nIDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgW0xhdG5dOyBbVGds Z10gOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbSXQgYXBwZWFycyB0aGF0IFRnbGcgaXMg bm90IGluIG1vZGVybiB1c2VdCjxicj5bdHJ1XSA7IFR1cm95byA7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO1tTeXJjXSA7PGJyPlt0dHRdIDsgVGF0IDsgJm5ic3A7IFtDeXJsXSA7PGJyPlt0 dXRdIDsgQWx0YWkgKEFsdGFpYz8pIDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgW0N5cmxdIDs8YnI+ W3R5XSA7ICZuYnNwO1RhaGl0aWFuIDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbTGF0bl0gOzxicj5b dWRtXSA7IFVkbXVydCA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tDeXJsXTsgW0xhdG5d IDs8YnI+W3VnXSA7ICZuYnNwO1VpZ2h1ciA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tB cmFiXTsgW0xhdG5dOyBbQ3lybF0gOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtb YWRkcyBMYXRuLCBDeXJsOyBpcyB0aGUKPGJyPmxhdHRlciBjb21tb24/ICZuYnNwO1JlbW92ZWQg VWlnaHVyXSZxdW90Ozxicj5bdmldIDsgJm5ic3A7VmlldG5hbWVzZSA7ICZuYnNwOyAmbmJzcDtb TGF0bl07IENodSBOb20gOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBbQ2h1IE5vbSB3b3VsZCBiZSBI YW5pKl08YnI+W3hhbF0gOyBLYWxteWsgOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbQ3ly bF0gOzxicj5beHNyXSA7IFNoZXJwYSA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tEZXZh XSA7PGJyPlt5cmtdIDsgTmVuZXRzIDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W0N5cmxd IDsKPGJyPjxicj4jIE1pc3NpbmcgTGFuZ3VhZ2UgQ29kZXM8YnI+PGJyPj8/PyA7ICZuYnNwOyBB aXNvciA7IFtDeXJsXTxicj4/Pz8gOyAmbmJzcDsgQXNzeXJpYW4gKG1vZGVybikgOyAmbmJzcDsg Jm5ic3A7IFtTeXJjXTxicj4/Pz8gOyAmbmJzcDsgQmFoYXNhIDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7W0xhdG5dPGJyPj8/PyA7ICZuYnNwOyBCYWxlYXIgOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtbTGF0bl08YnI+Pz8/IDsgJm5ic3A7IEJhbGthciA7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO1tDeXJsXTxicj4/Pz8gOyAmbmJzcDsgQnVnaXMgOyBbQnVnaV0KPGJyPj8/ PyA7ICZuYnNwOyBCdXJ5YXQgOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbQ3lybF08YnI+ Pz8/IDsgJm5ic3A7IENoYW0gOyAmbmJzcDtbQ2hhbV0qPGJyPj8/PyA7ICZuYnNwOyBDaGhhdHRp c2dhcmhpIDsgW0RldmFdPGJyPj8/PyA7ICZuYnNwOyBDaHVrY2hpIDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgW0N5cmxdPGJyPj8/PyA7ICZuYnNwOyBEdW5nYW4gOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtbQ3lybF08YnI+Pz8/IDsgJm5ic3A7IEVkbyA7ICZuYnNwOyBbTGF0bl08YnI+Pz8/ IDsgJm5ic3A7IEdhcnNodW5pIDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbU3lyY10KPGJyPj8/PyA7 ICZuYnNwOyBHYXNjb24gOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbTGF0bl08YnI+Pz8/ IDsgJm5ic3A7IEp1ZGV6bW8gOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBbSGVicl08YnI+Pz8/IDsg Jm5ic3A7IEthbmthbiA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tEZXZhXTxicj4/Pz8g OyAmbmJzcDsgS2hha2FzcyA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtDeXJsXTxicj4/Pz8gOyAm bmJzcDsgS29yeWFrIDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W0N5cmxdPGJyPj8/PyA7 ICZuYnNwOyBMYXBwIDsgJm5ic3A7W0xhdG5dPGJyPj8/PyA7ICZuYnNwOyBNb3JkdmluIDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgW0N5cmxdCjxicj4/Pz8gOyAmbmJzcDsgTmFnYSA7ICZuYnNwO1tM YXRuXTsgW0JlbmddPGJyPj8/PyA7ICZuYnNwOyBSaWFuZyA7IFtCZW5nXTxicj4/Pz8gOyAmbmJz cDsgU3dhZGF5YSA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtTeXJjXTxicj4/Pz8gOyAmbmJzcDsg VGFtYXppZ2h0IDsgJm5ic3A7ICZuYnNwOyBbVGZuZ10sIFtMYXRuXTxicj4/Pz8gOyAmbmJzcDsg VHNhbGFnaSA7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IChzZWUgQ2hlcm9rZWUpPGJyPj8/PyA7ICZu YnNwOyBUdXZhIDsgJm5ic3A7W0N5cmxdPGJyPj8/PyA7ICZuYnNwOyBVZGVraGUgOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtbQ3lybF0KPGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFp bF9xdW90ZSI+T24gOS8yNy8wNiwgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPkZyYW5rIEVs bGVybWFubjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpub2JvZHlAeHl6enkuY2xhcmFuZXQuZGUi Pm5vYm9keUB4eXp6eS5jbGFyYW5ldC5kZTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigy MDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAx ZXg7Ij4KSm9obiBDb3dhbiB3cm90ZTo8YnI+PGJyPiZndDsgSSdsbCBwb3N0IChzb21lIG9mKSB0 aGUgY3VycmVudCBzdGF0ZSBvZiB0aGluZ3Mgc2hvcnRseS48YnI+PGJyPkhlcmUncyBhIGxpc3Qg b2YgNjcgZGlmZmVyZW5jZXMgYmV0d2VlbiBMVFJVIGFuZCBDTERSIDEuNDxicj48YnI+TGluZXMg d2hlcmUgTFRSVSBoYXMgbm8gc2NyaXB0IGFuZCBDTERSIG1vcmUgdGhhbiBvbmUgYXJlPGJyPm1v c3QgcHJvYmFibHkgc2FuZSwgYnV0IGFueXRoaW5nIGVsc2Ugc2hvdWxkIGJlIGNoZWNrZWQ6Cjxi cj48YnI+bGFuZyBhYSZuYnNwOyZuYnNwO2x0cnUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtjbGRyIExhdG48YnI+bGFuZyBhayZuYnNwOyZuYnNwO2x0cnUmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjbGRyIExhdG48YnI+bGFuZyBheiZuYnNwOyZuYnNwO2x0 cnUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjbGRyIEFyYWIgQ3lybCBMYXRu PGJyPmxhbmcgYm8mbmJzcDsmbmJzcDtsdHJ1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Y2xkciBUaWJ0PGJyPmxhbmcgY3ImbmJzcDsmbmJzcDtsdHJ1Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2xkciBDYW5zIExhdG48YnI+bGFuZyBlZSZuYnNwOyZuYnNw O2x0cnUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjbGRyIExhdG48YnI+bGFu ZyBmeSZuYnNwOyZuYnNwO2x0cnUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtj bGRyIExhdG4KPGJyPmxhbmcgZ2QmbmJzcDsmbmJzcDtsdHJ1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Y2xkciBMYXRuPGJyPmxhbmcgaGEmbmJzcDsmbmJzcDtsdHJ1Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2xkciBBcmFiIExhdG48YnI+bGFuZyBobyZu YnNwOyZuYnNwO2x0cnUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjbGRyIExh dG48YnI+bGFuZyBpYSZuYnNwOyZuYnNwO2x0cnUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtjbGRyIExhdG48YnI+bGFuZyBpZyZuYnNwOyZuYnNwO2x0cnUmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjbGRyIExhdG48YnI+bGFuZyBpdSZuYnNwOyZuYnNwO2x0 cnUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjbGRyIENhbnMgQ3lybCBMYXRu PGJyPmxhbmcgamEmbmJzcDsmbmJzcDtsdHJ1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Y2xkciBIYW5pIEhpcmEgS2FuYQo8YnI+bGFuZyBrbyZuYnNwOyZuYnNwO2x0cnUmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjbGRyIEhhbmcgSGFuaTxicj5sYW5nIGtz Jm5ic3A7Jm5ic3A7bHRydSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NsZHIg QXJhYiBEZXZhPGJyPmxhbmcga3UmbmJzcDsmbmJzcDtsdHJ1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Y2xkciBBcmFiIEN5cmwgTGF0bjxicj5sYW5nIGt3Jm5ic3A7Jm5ic3A7 bHRydSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NsZHIgTGF0bjxicj5sYW5n IGt5Jm5ic3A7Jm5ic3A7bHRydSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Ns ZHIgQXJhYiBDeXJsPGJyPmxhbmcgbWkmbmJzcDsmbmJzcDtsdHJ1Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2xkciBMYXRuPGJyPgpsYW5nIG1uJm5ic3A7Jm5ic3A7bHRydSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NsZHIgQ3lybCBNb25nPGJyPmxhbmcg bW8mbmJzcDsmbmJzcDtsdHJ1IExhdG4gY2xkciBDeXJsIExhdG48YnI+bGFuZyBtcyZuYnNwOyZu YnNwO2x0cnUgTGF0biBjbGRyIEFyYWIgTGF0bjxicj5sYW5nIG9jJm5ic3A7Jm5ic3A7bHRydSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NsZHIgTGF0bjxicj5sYW5nIG9zJm5i c3A7Jm5ic3A7bHRydSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NsZHIgTGF0 bjxicj5sYW5nIHBhJm5ic3A7Jm5ic3A7bHRydSBHdXJ1IGNsZHIgQXJhYiBHdXJ1PGJyPmxhbmcg cm0mbmJzcDsmbmJzcDtsdHJ1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2xk ciBMYXRuCjxicj5sYW5nIHNhJm5ic3A7Jm5ic3A7bHRydSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO2NsZHIgRGV2YTxicj5sYW5nIHNkJm5ic3A7Jm5ic3A7bHRydSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NsZHIgQXJhYiBEZXZhPGJyPmxhbmcgc2UmbmJz cDsmbmJzcDtsdHJ1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2xkciBMYXRu PGJyPmxhbmcgc2gmbmJzcDsmbmJzcDtsdHJ1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Y2xkciBMYXRuPGJyPmxhbmcgc3ImbmJzcDsmbmJzcDtsdHJ1Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2xkciBDeXJsIExhdG48YnI+bGFuZyB0ZyZuYnNwOyZuYnNw O2x0cnUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjbGRyIEFyYWIgQ3lybCBM YXRuPGJyPmxhbmcgdGsmbmJzcDsmbmJzcDtsdHJ1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Y2xkciBBcmFiIEN5cmwgTGF0bgo8YnI+bGFuZyB0ciZuYnNwOyZuYnNwO2x0cnUg TGF0biBjbGRyIEFyYWIgTGF0bjxicj5sYW5nIHR0Jm5ic3A7Jm5ic3A7bHRydSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NsZHIgQ3lybDxicj5sYW5nIHVnJm5ic3A7Jm5ic3A7 bHRydSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NsZHIgQXJhYjxicj5sYW5n IHV6Jm5ic3A7Jm5ic3A7bHRydSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Ns ZHIgQXJhYiBDeXJsIExhdG48YnI+bGFuZyB5byZuYnNwOyZuYnNwO2x0cnUmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjbGRyIExhdG48YnI+bGFuZyB6aCZuYnNwOyZuYnNwO2x0 cnUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjbGRyIEJvcG8gSGFuaSBIYW5z IEhhbnQKPGJyPmxhbmcgYmFsIGx0cnUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtjbGRyIEFyYWIgTGF0bjxicj5sYW5nIGJ5biBsdHJ1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Y2xkciBFdGhpPGJyPmxhbmcgY2NoIGx0cnUmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtjbGRyIExhdG48YnI+bGFuZyBjaHIgbHRydSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NsZHIgQ2hlciBMYXRuPGJyPmxhbmcgY29wIGx0cnUmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjbGRyIEFyYWIgQ29wdDxicj5sYW5nIGZp bCBsdHJ1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2xkciBMYXRuPGJyPmxh bmcgZml1IGx0cnUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjbGRyIExhdG4K PGJyPmxhbmcgZnVyIGx0cnUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjbGRy IExhdG48YnI+bGFuZyBnYWEgbHRydSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O2NsZHIgTGF0bjxicj5sYW5nIGdleiBsdHJ1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Y2xkciBFdGhpPGJyPmxhbmcgZ3N3IGx0cnUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtjbGRyIExhdG48YnI+bGFuZyBoYXcgbHRydSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO2NsZHIgTGF0bjxicj5sYW5nIGthaiBsdHJ1Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2xkciBMYXRuPGJyPmxhbmcga2FtIGx0cnUmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjbGRyIExhdG4KPGJyPmxhbmcga2NnIGx0cnUmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjbGRyIExhdG48YnI+bGFuZyBrZm8gbHRy dSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NsZHIgTGF0bjxicj5sYW5nIGtw ZSBsdHJ1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2xkciBMYXRuPGJyPmxh bmcgc2lkIGx0cnUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjbGRyIExhdG48 YnI+bGFuZyBzbWEgbHRydSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NsZHIg TGF0bjxicj5sYW5nIHNtaSBsdHJ1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Y2xkciBMYXRuPGJyPmxhbmcgc21qIGx0cnUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtjbGRyIExhdG4KPGJyPmxhbmcgc21uIGx0cnUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtjbGRyIExhdG48YnI+bGFuZyBzbXMgbHRydSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO2NsZHIgTGF0bjxicj5sYW5nIHN5ciBsdHJ1Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2xkciBTeXJjPGJyPmxhbmcgdGV0IGx0cnUmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjbGRyIExhdG48YnI+bGFuZyB0aWcgbHRydSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NsZHIgRXRoaTxicj5sYW5nIHdhbCBsdHJ1 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2xkciBFdGhpPGJyPjxicj48YnI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPGJyPklldGYt bGFuZ3VhZ2VzIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86SWV0Zi1sYW5ndWFnZXNA YWx2ZXN0cmFuZC5ubyI+SWV0Zi1sYW5ndWFnZXNAYWx2ZXN0cmFuZC5ubzwvYT48YnI+PGEgaHJl Zj0iaHR0cDovL3d3dy5hbHZlc3RyYW5kLm5vL21haWxtYW4vbGlzdGluZm8vaWV0Zi1sYW5ndWFn ZXMiPmh0dHA6Ly93d3cuYWx2ZXN0cmFuZC5uby9tYWlsbWFuL2xpc3RpbmZvL2lldGYtbGFuZ3Vh Z2VzCjwvYT48YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4K ------=_Part_10399_4659988.1159396789160-- --===============0330164355== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0330164355==-- From ltru-bounces@ietf.org Wed Sep 27 20:58:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSkEV-0003rg-1u; Wed, 27 Sep 2006 20:58:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSkET-0003rF-IU for ltru@lists.ietf.org; Wed, 27 Sep 2006 20:58:33 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSkEQ-0007kj-5q for ltru@lists.ietf.org; Wed, 27 Sep 2006 20:58:33 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GSkE6-0005NK-SF for ltru@lists.ietf.org; Thu, 28 Sep 2006 02:58:10 +0200 Received: from pd9fbacab.dip0.t-ipconnect.de ([217.251.172.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Sep 2006 02:58:10 +0200 Received: from nobody by pd9fbacab.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Sep 2006 02:58:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 28 Sep 2006 02:57:42 +0200 Organization: Lines: 13 Message-ID: <451B1E06.5C12@xyzzy.claranet.de> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbacab.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] Re: Suppress-Script batch 1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > it needs to be confirmed that such a request relates to > actual usage, and is not a "test" of the system or an > attempt to "prove" something about the system or its > participants or related SDOs. 1: The intended cleanup of the missing Suppress-Scripts did not work so far. 2: What's okay for ngo should be also okay for fy and frr. 3: I consider statements that my registration request for frr was a bad faith effort as insulting. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 27 22:58:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSm6B-00082P-Cz; Wed, 27 Sep 2006 22:58:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSm6A-00082K-6L for ltru@ietf.org; Wed, 27 Sep 2006 22:58:06 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSm64-0006Ek-SE for ltru@ietf.org; Wed, 27 Sep 2006 22:58:06 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GSm61-0008Ac-8O; Wed, 27 Sep 2006 22:57:57 -0400 Date: Wed, 27 Sep 2006 22:57:57 -0400 To: Mark Davis Message-ID: <20060928025757.GC3780@ccil.org> References: <45193FC2.26E2@xyzzy.claranet.de> <20060926185837.GB20579@ccil.org> <451A335A.56DC@xyzzy.claranet.de> <30b660a20609271539pac3aa26w70e7e447b5981a9e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20609271539pac3aa26w70e7e447b5981a9e@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: Frank Ellermann , Michael Everson , LTRU Working Group , ietf-languages@alvestrand.no Subject: [Ltru] CLDR mysteries solved! X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > In particular, I had asked on this list if anyone knew anything about > the couple of dozen purported languages at the end for which Magda > couldn't find 639-3 language codes. Hearing no response, we will > probably just remove them from the Unicode site as bogus. Google search of www.ethnologue.com is your friend. > ??? ; Aisor ; [Cyrl] > ??? ; Assyrian (modern) ; [Syrc] Synonyms for Assyrian Neo-Aramaic (syr-aii). > ??? ; Bahasa ; [Latn] This is the Malay/Indonesian word for "language", so it's probably a synonym for either one (they are very similar but not identical). > ??? ; Balear ; [Latn] Dialect of Catalan spoken in the Balearic islands. > ??? ; Balkar ; [Cyrl] Dialect of Karachay-Balkar (krc). > ??? ; Bugis ; [Bugi] Synonym for Buginese (bug) > ??? ; Buryat ; [Cyrl] Synonym for Russia Buriat (bxr) > ??? ; Cham ; [Cham]* Could be Western Cham (cja) in Cambodia or Eastern Cham (cjm) in Vietnam. > ??? ; Chhattisgarhi ; [Deva] Code hne. > ??? ; Chukchi ; [Cyrl] Should be Chukot (ckt). "Chukchi" is the ethnonym. > ??? ; Dungan ; [Cyrl] Code dng. Linguistically part of the Mandarin Chinese dialect continuum, but sociolinguistically separate because written in Cyrillic and spoken in Russia. > ??? ; Edo ; [Latn] Code bin. > ??? ; Garshuni ; [Syrc] Apparently means ar-Syrc. See http://en.wikipedia.org/wiki/Garshuni . > ??? ; Gascon ; [Latn] Code oc-gsc (part of the Occitan macrolanguage). > ??? ; Judezmo ; [Hebr] Synonym for Ladino (lad). > ??? ; Kankan ; [Deva] Synonym for Eastern Maninkakan (emk) > ??? ; Khakass ; [Cyrl] Spelling error or synonym for Khakas (kjh) > ??? ; Koryak ; [Cyrl] Code kpy. > ??? ; Lapp ; [Latn] One of the Saami languages ("Lapp" is derogatory). See http://www.ethnologue.com/show_family.asp?subid=90977 . > ??? ; Mordvin ; [Cyrl] A genetic grouping comprising Erzya (myv) and Moksha (mdf). > ??? ; Naga ; [Latn]; [Beng] A genetic grouping comprising 25 languages, most called "X Naga"; see http://www.ethnologue.com/show_family.asp?subid=92044 . Also Naga Pidgin (nag). > ??? ; Riang ; [Beng] Code ril. > ??? ; Swadaya ; [Syrc] Dialect of syr-aii (see above). > ??? ; Tamazight ; [Tfng], [Latn] Probably Central Atlas Tamazight (tzm), but might be intended to include two other Tamazight languages (tjo, tia). > ??? ; Tsalagi ; (see Cherokee) Synonym for Cherokee (chr). > ??? ; Tuva ; [Cyrl] Tuvin (tyv); "Tuva" is the locality name. > ??? ; Udekhe ; [Cyrl] Synonym for Udihe (ude). -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Be yourself. Especially do not feign a working knowledge of RDF where no such knowledge exists. Neither be cynical about RELAX NG; for in the face of all aridity and disenchantment in the world of markup, James Clark is as perennial as the grass. --DeXiderata, Sean McGrath _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 00:30:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSnX6-0003Np-Sr; Thu, 28 Sep 2006 00:30:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSnX5-0003Nf-H1 for ltru@ietf.org; Thu, 28 Sep 2006 00:29:59 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSnX1-0000YW-Jq for ltru@ietf.org; Thu, 28 Sep 2006 00:29:59 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8S4Tn63013455 for ; Thu, 28 Sep 2006 13:29:50 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4f60_fa860e82_4ea9_11db_9aab_0014221fa3c9; Thu, 28 Sep 2006 13:29:49 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:53885) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 28 Sep 2006 13:29:46 +0900 Message-Id: <6.0.0.20.2.20060928104743.098b7df0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 28 Sep 2006 10:48:59 +0900 To: Karen_Broome@spe.sony.com, "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: Suppress-Script batch 1 In-Reply-To: References: <030301c6e258$7e923bb0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Karen, As a technical contributor, I think you raise a very valid point that should be documented clearly. As a co-chair, I'd like to ask you to propose specific wording, and a place to put it. This is the fastest way to move this issue forward. Regards, Martin. At 02:52 06/09/28, Karen_Broome@spe.sony.com wrote: >I still think the text of RFC 4646 and structure leans strongly toward an assumption that all language is written. Increasingly web content features animated talking heads or video, and this content may need language tagging as well. > >Motion picture applications -- including television, broadcast, Digital Cinema, podcast, phonecast, multilingual electronic program guides, and local/national/university archives -- also require language tagging. The text of RFC 4646 indicates that the script can be omitted when it can be assumed. It doesn't mention that in an increasing number of cases, the assignment of a script tag is completely inappropriate. > >Regards, > >Karen Broome >Metadata Systems Designer >Sony Pictures Entertainment > > > > > >"Doug Ewell" > >09/27/2006 10:15 AM >To >"LTRU Working Group" >cc >Subject >[Ltru] Re: Suppress-Script batch 1 > > > > >John Cowan wrote: > >> Remember that the criterion for including a Suppress-Script is that >> the script is always used for the language except in a few highly >> restricted domains, such as writing for the blind, scholarly >> transliteration, transcription for use in another language, and when >> the standard script is not available. > >I wish we had that explanation somewhere in RFC 4646. It's better than >most of the explanations I've seen, certainly better than any I've >written. > >-- >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 >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 00:54:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSnum-0001lW-Vs; Thu, 28 Sep 2006 00:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSnum-0001lI-5q for ltru@ietf.org; Thu, 28 Sep 2006 00:54:28 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSnuk-0002qn-GR for ltru@ietf.org; Thu, 28 Sep 2006 00:54:28 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8S4sPe3009895 for ; Thu, 28 Sep 2006 13:54:25 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4f5f_6a16478c_4ead_11db_9e85_0014221fa3c9; Thu, 28 Sep 2006 13:54:25 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:36655) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 28 Sep 2006 13:54:22 +0900 Message-Id: <6.0.0.20.2.20060928133744.04e41840@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 28 Sep 2006 13:53:44 +0900 To: "Doug Ewell" , "LTRU Working Group" , From: Martin Duerst In-Reply-To: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [Ltru] Korean (and Japanese) (was: Re: Suppress-Script batch 1) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 03:06 06/09/28, Doug Ewell wrote: >Last March I began a small research project to determine whether Korean should have a Suppress-Script of Hangul. I read books, scanned Korean-language newspapers published in Seoul and in Los Angeles, checked numerous Web sites, talked to native Korean speakers in person and by e-mail. The result was that Hangul is, in fact, used an overwhelming proportion of the time to write modern Korean -- a colleague at work actually used the word "overwhelming" -- but there is still a certain, tiny, regular pattern of usage of Han (hanja) in scholarly works and newspapers. "Regular" was the key here. So I concluded that a Suppress-Script for Korean actually would NOT be a good idea, which is not what I expected to find. This is a particularly tricky one. In modern Korean, what you may want to distinguish in practice is texts written exclusively in Hangul and texts written mostly in Hangul, but with a few Hanja interspersed. Historically, you also want to distinguish texts written exclusively in Hanja. The "a few Hanja interspersed" can, as far as I understand, go from a very low percentage (such as <1%, an example I have seen is books for the board game of Go, where Hanja are used for 'black' and 'white', but nothing else) to a much higher percentage (a potential example might be a political treatise where all the names and all the technical terms are in Hanja). In terms of readability, these two examples, althoug both mixtures, have to be evaluated quite differently: The former is about as easy to read as pure Hangul, while the later is quite a bit more difficult. In that sense, one can ask oneself whether an example like the former cannoFrom ltru-bounces@ietf.org Thu Sep 28 00:54:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSnum-0001lW-Vs; Thu, 28 Sep 2006 00:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSnum-0001lI-5q for ltru@ietf.org; Thu, 28 Sep 2006 00:54:28 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSnuk-0002qn-GR for ltru@ietf.org; Thu, 28 Sep 2006 00:54:28 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8S4sPe3009895 for ; Thu, 28 Sep 2006 13:54:25 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4f5f_6a16478c_4ead_11db_9e85_0014221fa3c9; Thu, 28 Sep 2006 13:54:25 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:36655) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 28 Sep 2006 13:54:22 +0900 Message-Id: <6.0.0.20.2.20060928133744.04e41840@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 28 Sep 2006 13:53:44 +0900 To: "Doug Ewell" , "LTRU Working Group" , From: Martin Duerst In-Reply-To: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [Ltru] Korean (and Japanese) (was: Re: Suppress-Script batch 1) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 03:06 06/09/28, Doug Ewell wrote: >Last March I began a small research project to determine whether Korean should have a Suppress-Script of Hangul. I read books, scanned Korean-language newspapers published in Seoul and in Los Angeles, checked numerous Web sites, talked to native Korean speakers in person and by e-mail. The result was that Hangul is, in fact, used an overwhelming proportion of the time to write modern Korean -- a colleague at work actually used the word "overwhelming" -- but there is still a certain, tiny, regular pattern of usage of Han (hanja) in scholarly works and newspapers. "Regular" was the key here. So I concluded that a Suppress-Script for Korean actually would NOT be a good idea, which is not what I expected to find. This is a particularly tricky one. In modern Korean, what you may want to distinguish in practice is texts written exclusively in Hangul and texts written mostly in Hangul, but with a few Hanja interspersed. Historically, you also want to distinguish texts written exclusively in Hanja. The "a few Hanja interspersed" can, as far as I understand, go from a very low percentage (such as <1%, an example I have seen is books for the board game of Go, where Hanja are used for 'black' and 'white', but nothing else) to a much higher percentage (a potential example might be a political treatise where all the names and all the technical terms are in Hanja). In terms of readability, these two examples, althoug both mixtures, have to be evaluated quite differently: The former is about as easy to read as pure Hangul, while the later is quite a bit more difficult. In that sense, one can ask oneself whether an example like the former cannot just be tagged as Hangul, in the same way as e.g. a Latin text with an occasional Greek or other character would still be tagged as Latin. For the later example, the question is whether something similar to Subtag: Jpan Description: Japanese (alias for Han + Hiragana + Katakana) should be defined for the Korean case. The problem is that while conventions for what to write with Kanji, Hiragana, and Katakana in modern Japanese are quite well established, the practice is quite a bit more varying in Korean, the way I understand it. Speaking about Japanese, I'm quite surprised that we don't have Supress-script: Jpan at Type: language Subtag: ja Description: Japanese Added: 2005-10-16 When something is tagged ja, the assumption is that it's written in Kanji-Kana mixture, because that's how Japanese is written. Not having a Suppress-script would mean that strictly speaking, ja-Jpan should be used, which nobody does and would be silly anyway. >One important fact to keep in mind is that Suppress-Script values may be not only added, but also removed (Section 3.4, item 7). If we make a mistake, we can go back and fix it. Oh, at least one thing that we can fix. We should definitely leave it that way. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 00:54:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSnum-0001lN-T8; Thu, 28 Sep 2006 00:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSnul-0001lD-M7 for ltru@ietf.org; Thu, 28 Sep 2006 00:54:27 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSnuj-0002oz-Pn for ltru@ietf.org; Thu, 28 Sep 2006 00:54:27 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8S4sM7t009882 for ; Thu, 28 Sep 2006 13:54:22 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4f7c_689e78d4_4ead_11db_8167_0014221fa3c9; Thu, 28 Sep 2006 13:54:22 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:36655) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 28 Sep 2006 13:54:19 +0900 Message-Id: <6.0.0.20.2.20060928133247.04e41550@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 28 Sep 2006 13:33:15 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: Suppress-Script batch 1 In-Reply-To: <030301c6e258$7e923bb0$6401a8c0@DGBP7M81> References: <030301c6e258$7e923bb0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 to Doug's proposal to include John's text into 4646bis. Regards, Martin. At 02:15 06/09/28, Doug Ewell wrote: >John Cowan wrote: > >> Remember that the criterion for including a Supprest just be tagged as Hangul, in the same way as e.g. a Latin text with an occasional Greek or other character would still be tagged as Latin. For the later example, the question is whether something similar to Subtag: Jpan Description: Japanese (alias for Han + Hiragana + Katakana) should be defined for the Korean case. The problem is that while conventions for what to write with Kanji, Hiragana, and Katakana in modern Japanese are quite well established, the practice is quite a bit more varying in Korean, the way I understand it. Speaking about Japanese, I'm quite surprised that we don't have Supress-script: Jpan at Type: language Subtag: ja Description: Japanese Added: 2005-10-16 When something is tagged ja, the assumption is that it's written in Kanji-Kana mixture, because that's how Japanese is written. Not having a Suppress-script would mean that strictly speaking, ja-Jpan should be used, which nobody does and would be silly anyway. >One important fact to keep in mind is that Suppress-Script values may be not only added, but also removed (Section 3.4, item 7). If we make a mistake, we can go back and fix it. Oh, at least one thing that we can fix. We should definitely leave it that way. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 00:54:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSnum-0001lN-T8; Thu, 28 Sep 2006 00:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSnul-0001lD-M7 for ltru@ietf.org; Thu, 28 Sep 2006 00:54:27 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSnuj-0002oz-Pn for ltru@ietf.org; Thu, 28 Sep 2006 00:54:27 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8S4sM7t009882 for ; Thu, 28 Sep 2006 13:54:22 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4f7c_689e78d4_4ead_11db_8167_0014221fa3c9; Thu, 28 Sep 2006 13:54:22 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:36655) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 28 Sep 2006 13:54:19 +0900 Message-Id: <6.0.0.20.2.20060928133247.04e41550@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 28 Sep 2006 13:33:15 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: Suppress-Script batch 1 In-Reply-To: <030301c6e258$7e923bb0$6401a8c0@DGBP7M81> References: <030301c6e258$7e923bb0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 to Doug's proposal to include John's text into 4646bis. Regards, Martin. At 02:15 06/09/28, Doug Ewell wrote: >John Cowan wrote: > >> Remember that the criterion for including a Suppress-Script is that the script is always used for the language except in a few highly restricted domains, such as writing for the blind, scholarly transliteration, transcription for use in another language, and when the standard script is not available. > >I wish we had that explanation somewhere in RFC 4646. It's better than most of the explanations I've seen, certainly better than any I've written. > >-- >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 >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru s-Script is that the script is always used for the language except in a few highly restricted domains, such as writing for the blind, scholarly transliteration, transcription for use in another language, and when the standard script is not available. > >I wish we had that explanation somewhere in RFC 4646. It's better than most of the explanations I've seen, certainly better than any I've written. > >-- >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 >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 00:54:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSnur-0001nS-Oe; Thu, 28 Sep 2006 00:54:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSnum-0001lO-Sv for ltru@ietf.org; Thu, 28 Sep 2006 00:54:28 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSnuk-0002p9-0L for ltru@ietf.org; Thu, 28 Sep 2006 00:54:28 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8S4sOBT015621 for ; Thu, 28 Sep 2006 13:54:24 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 1d30_696ab3fe_4ead_11db_9670_0014221f2a2d; Thu, 28 Sep 2006 13:54:23 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:36655) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 28 Sep 2006 13:54:21 +0900 Message-Id: <6.0.0.20.2.20060928133408.04dc75c0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 28 Sep 2006 13:36:54 +0900 To: John Cowan , Frank Ellermann From: Martin Duerst Subject: Re: [Ltru] Suppress-Script batch 1 In-Reply-To: <20060927155143.GI22233@ccil.org> References: <45193FC2.26E2@xyzzy.claranet.de> <20060926185837.GB20579@ccil.org> <451A335A.56DC@xyzzy.claranet.de> <20060927155143.GI22233@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 00:51 06/09/28, John Cowan wrote: >rm Raeto-Romance Latn I can definitely confirm that Raeto-Romance is written in Latin. Although this was some time ago, I have spent altogether quite a few weeks in areas where Raeto-Romance was the primary languge. Never was any other script than Latin used. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 01:02:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSo2t-0006KJ-0a; Thu, 28 Sep 2006 01:02:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSmJR-0006Ox-8f for ltru@ietf.org; Wed, 27 Sep 2006 23:11:49 -0400 Received: from ms-smtp-04.rdc-kc.rr.com ([24.94.166.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSmJL-0000dr-OZ for ltru@ietf.org; Wed, 27 Sep 2006 23:11:49 -0400 Received: from [65.26.17.212] (CPE-65-26-17-212.kc.res.rr.com [65.26.17.212]) by ms-smtp-04.rdc-kc.rr.com (8.13.6/8.13.6) with ESMTP id k8S3BUK8003039; Wed, 27 Sep 2006 22:11:31 -0500 (CDT) Message-ID: <451B3D6B.6080105@gmail.com> Date: Wed, 27 Sep 2006 22:11:39 -0500 From: =?UTF-8?B?IlJlc2hhdCBTYWJpcSAoUmXFn2F0KSI=?= User-Agent: Mozilla Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Mark Davis References: <45193FC2.26E2@xyzzy.claranet.de> <20060926185837.GB20579@ccil.org> <451A335A.56DC@xyzzy.claranet.de> <30b660a20609271539pac3aa26w70e7e447b5981a9e@mail.gmail.com> In-Reply-To: <30b660a20609271539pac3aa26w70e7e447b5981a9e@mail.gmail.com> X-Enigmail-Version: 0.94.1.0 OpenPGP: id=262839AF; url=http://keyserver.veridis.com:11371 Content-Type: text/plain; charset=UTF-8 X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ms-smtp-04.rdc-kc.rr.com id k8S3BUK8003039 X-Spam-Score: 0.5 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-Mailman-Approved-At: Thu, 28 Sep 2006 01:02:50 -0400 Cc: Frank Ellermann , Michael Everson , LTRU Working Group , ietf-languages@alvestrand.no Subject: [Ltru] Re: Suppress-Script candidates (was: Re: frr, fy, ngo, tt) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Being a Tatar (OK to call me Bashqort too i guess), and not having lived in all of these places i'd still like to save a few Languages from delettion from unicode site, plus a few more comments. Please see my humble feedback below (i tried to phrase sentences i was less sure about in a way that wouldn't put my credibility on the line): Mark Davis yazm=C4=B1=C5=9F: > If you are going to do any analysis of the differences, please take a > look also at my message of ... > [ba] ; Bashkir ; [Cyrl] ; The native spelling of the language in English would be: Bashqort. > [ce] ; Chechen ; [Cyrl] ; This gets into politics, but while Chechen republic was de-facto independent, AFAIK, the official alphabet was Latn. > [kaa] ; Karakalpak ; [Cyrl] The native spelling is: Qaraqalpaq. Latn has been becoming official sicne 1991, but according to wiki slower than in Uzbekistan in general. > [krc] ; Karachay ; [Cyrl] The native spelling is: Qarachay. I don't know first hand, but what i'm reading is Qarachay and Balqar (Malqar) are almost the same (two letters are different in some suffixes or something like that; probably less differences than between Tatar and Bashqort), and the name that refers to both of them is Alan language. Also there are projects of adopting Latin, but not sure if it's just intelligentsia or majority of electronic usage, etc. > ??? ; Balkar ; [Cyrl] I tend to think that Balqar is Qarachay spelling, and Malqar is the native way to say this. See above for references to Alan language, as a cumulative name, and Latn topic. Both are fairly intelligible to Tatars. > ??? ; Buryat ; [Cyrl] Is a variation of Mongol. > ??? ; Khakass ; [Cyrl] Is a Turkic language, but from what i'm reading there's only 65K speakers left. Might be endangered. > ??? ; Tuva ; [Cyrl] Is a Turkic language. I tend to think native spelling in English would be: Tywa. P.S. I'll try to keep up if there's more discussion on these, but forgive me in advance if i miss something. ;) - -- My public GPG key (ID 0x262839AF) is at: http://keyserver.veridis.com:113= 71 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFFGz1qO75ytyYoOa8RArlTAJ9/XBiThW0SWGhqFjEypRT319B5wACgqeYS 0JvnRJ3jM1RIVwIhvgPCGf4=3D =3DmLum -----END PGP SIGNATURE----- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 01:02:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSo2t-0006KN-2z; Thu, 28 Sep 2006 01:02:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSmPG-0002m1-H9 for ltru@ietf.org; Wed, 27 Sep 2006 23:17:50 -0400 Received: from ms-smtp-01.rdc-kc.rr.com ([24.94.166.115]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSmPE-0003V0-08 for ltru@ietf.org; Wed, 27 Sep 2006 23:17:50 -0400 Received: from [65.26.17.212] (CPE-65-26-17-212.kc.res.rr.com [65.26.17.212]) by ms-smtp-01.rdc-kc.rr.com (8.13.6/8.13.6) with ESMTP id k8S3HOXl026926; Wed, 27 Sep 2006 22:17:25 -0500 (CDT) Message-ID: <451B3ECB.8000206@gmail.com> Date: Wed, 27 Sep 2006 22:17:31 -0500 From: =?UTF-8?B?IlJlc2hhdCBTYWJpcSAoUmXFn2F0KSI=?= User-Agent: Mozilla Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: John Cowan References: <45193FC2.26E2@xyzzy.claranet.de> <20060926185837.GB20579@ccil.org> <451A335A.56DC@xyzzy.claranet.de> <30b660a20609271539pac3aa26w70e7e447b5981a9e@mail.gmail.com> <20060928025757.GC3780@ccil.org> In-Reply-To: <20060928025757.GC3780@ccil.org> X-Enigmail-Version: 0.94.1.0 OpenPGP: id=262839AF; url=http://keyserver.veridis.com:11371 Content-Type: text/plain; charset=UTF-8 X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ms-smtp-01.rdc-kc.rr.com id k8S3HOXl026926 X-Spam-Score: 0.5 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Thu, 28 Sep 2006 01:02:50 -0400 Cc: Frank Ellermann , Michael Everson , LTRU Working Group , ietf-languages@alvestrand.no Subject: [Ltru] Re: CLDR mysteries solved! X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Cowan yazm=C4=B1=C5=9F: > Mark Davis scripsit: >=20 >> In particular, I had asked on this list if anyone knew anything about >> the couple of dozen purported languages at the end for which Magda >> couldn't find 639-3 language codes. Hearing no response, we will >> probably just remove them from the Unicode site as bogus. =20 >=20 > Google search of www.ethnologue.com is your friend. >=20 ... Looks like my feedback is just a partial confirmation on John's feedback. - -- My public GPG key (ID 0x262839AF) is at: http://keyserver.veridis.com:113= 71 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFFGz7LO75ytyYoOa8RAjbAAKCnDO1YD3F4CZA7i4yBuWESZaeB6QCfaZfL 4YnxpiQux8kIReF9O8UA7qU=3D =3DC7XW -----END PGP SIGNATURE----- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 01:02:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSo2t-0006KJ-0a; Thu, 28 Sep 2006 01:02:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSmJR-0006Ox-8f for ltru@ietf.org; Wed, 27 Sep 2006 23:11:49 -0400 Received: from ms-smtp-04.rdc-kc.rr.com ([24.94.166.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSmJL-0000dr-OZ for ltru@ietf.org; Wed, 27 Sep 2006 23:11:49 -0400 Received: from [65.26.17.212] (CPE-65-26-17-212.kc.res.rr.com [65.26.17.212]) by ms-smtp-04.rdc-kc.rr.com (8.13.6/8.13.6) with ESMTP id k8S3BUK8003039; Wed, 27 Sep 2006 22:11:31 -0500 (CDT) Message-ID: <451B3D6B.6080105@gmail.com> Date: Wed, 27 Sep 2006 22:11:39 -0500 From: =?UTF-8?B?IlJlc2hhdCBTYWJpcSAoUmXFn2F0KSI=?= User-Agent: Mozilla Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Mark Davis References: <45193FC2.26E2@xyzzy.claranet.de> <20060926185837.GB20579@ccil.org> <451A335A.56DC@xyzzy.claranet.de> <30b660a20609271539pac3aa26w70e7e447b5981a9e@mail.gmail.com> In-Reply-To: <30b660a20609271539pac3aa26w70e7e447b5981a9e@mail.gmail.com> X-Enigmail-Version: 0.94.1.0 OpenPGP: id=262839AF; url=http://keyserver.veridis.com:11371 Content-Type: text/plain; charset=UTF-8 X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ms-smtp-04.rdc-kc.rr.com id k8S3BUK8003039 X-Spam-Score: 0.5 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-Mailman-Approved-At: Thu, 28 Sep 2006 01:02:50 -0400 Cc: Frank Ellermann , Michael Everson , LTRU Working Group , ietf-languages@alvestrand.no Subject: [Ltru] Re: Suppress-Script candidates (was: Re: frr, fy, ngo, tt) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Being a Tatar (OK to call me Bashqort too i guess), and not having lived in all of these places i'd still like to save a few Languages from delettion from unicode site, plus a few more comments. Please see my humble feedback below (i tried to phrase sentences i was less sure about in a way that wouldn't put my credibility on the line): Mark Davis yazm=C4=B1=C5=9F: > If you are going to do any analysis of the differences, please take a > look also at my message of ... > [ba] ; Bashkir ; [Cyrl] ; The native spelling of the language in English would be: Bashqort. > [ce] ; Chechen ; [Cyrl] ; This gets into politics, but while Chechen republic was de-facto independent, AFAIK, the official alphabet was Latn. > [kaa] ; Karakalpak ; [Cyrl] The native spelling is: Qaraqalpaq. Latn has been becoming official sicne 1991, but according to wiki slower than in Uzbekistan in general. > [krc] ; Karachay ; [Cyrl] The native spelling is: Qarachay. I don't know first hand, but what i'm reading is Qarachay and Balqar (Malqar) are almost the same (two letters are different in some suffixes or something like that; probably less differences than between Tatar and Bashqort), and the name that refers to both of them is Alan language. Also there are projects of adopting Latin, but not sure if it's just intelligentsia or majority of electronic usage, etc. > ??? ; Balkar ; [Cyrl] I tend to think that Balqar is Qarachay spelling, and Malqar is the native way to say this. See above for references to Alan language, as a cumulative name, and Latn topic. Both are fairly intelligible to Tatars. > ??? ; Buryat ; [Cyrl] Is a variation of Mongol. > ??? ; Khakass ; [Cyrl] Is a Turkic language, but from what i'm reading there's only 65K speakers left. Might be endangered. > ??? ; Tuva ; [Cyrl] Is a Turkic language. I tend to think native spelling in English would be: Tywa. P.S. I'll try to keep up if there's more discussion on these, but forgive me in advance if i miss something. ;) - -- My public GPG key (ID 0x262839AF) is at: http://keyserver.veridis.com:113= 71 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFFGz1qO75ytyYoOa8RArlTAJ9/XBiThW0SWGhqFjEypRT319B5wACgqeYS 0JvnRJ3jM1RIVwIhvgPCGf4=3D =3DmLum -----END PGP SIGNATURE----- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 01:02:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSo2t-0006KN-2z; Thu, 28 Sep 2006 01:02:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSmPG-0002m1-H9 for ltru@ietf.org; Wed, 27 Sep 2006 23:17:50 -0400 Received: from ms-smtp-01.rdc-kc.rr.com ([24.94.166.115]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSmPE-0003V0-08 for ltru@ietf.org; Wed, 27 Sep 2006 23:17:50 -0400 Received: from [65.26.17.212] (CPE-65-26-17-212.kc.res.rr.com [65.26.17.212]) by ms-smtp-01.rdc-kc.rr.com (8.13.6/8.13.6) with ESMTP id k8S3HOXl026926; Wed, 27 Sep 2006 22:17:25 -0500 (CDT) Message-ID: <451B3ECB.8000206@gmail.com> Date: Wed, 27 Sep 2006 22:17:31 -0500 From: =?UTF-8?B?IlJlc2hhdCBTYWJpcSAoUmXFn2F0KSI=?= User-Agent: Mozilla Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: John Cowan References: <45193FC2.26E2@xyzzy.claranet.de> <20060926185837.GB20579@ccil.org> <451A335A.56DC@xyzzy.claranet.de> <30b660a20609271539pac3aa26w70e7e447b5981a9e@mail.gmail.com> <20060928025757.GC3780@ccil.org> In-Reply-To: <20060928025757.GC3780@ccil.org> X-Enigmail-Version: 0.94.1.0 OpenPGP: id=262839AF; url=http://keyserver.veridis.com:11371 Content-Type: text/plain; charset=UTF-8 X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ms-smtp-01.rdc-kc.rr.com id k8S3HOXl026926 X-Spam-Score: 0.5 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Thu, 28 Sep 2006 01:02:50 -0400 Cc: Frank Ellermann , Michael Everson , LTRU Working Group , ietf-languages@alvestrand.no Subject: [Ltru] Re: CLDR mysteries solved! X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Cowan yazm=C4=B1=C5=9F: > Mark Davis scripsit: >=20 >> In particular, I had asked on this list if anyone knew anything about >> the couple of dozen purported languages at the end for which Magda >> couldn't find 639-3 language codes. Hearing no response, we will >> probably just remove them from the Unicode site as bogus. =20 >=20 > Google search of www.ethnologue.com is your friend. >=20 ... Looks like my feedback is just a partial confirmation on John's feedback. - -- My public GPG key (ID 0x262839AF) is at: http://keyserver.veridis.com:113= 71 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFFGz7LO75ytyYoOa8RAjbAAKCnDO1YD3F4CZA7i4yBuWESZaeB6QCfaZfL 4YnxpiQux8kIReF9O8UA7qU=3D =3DC7XW -----END PGP SIGNATURE----- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 02:51:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSpjh-0002Yq-8B; Thu, 28 Sep 2006 02:51:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSpje-0002QM-Q9 for ltru@ietf.org; Thu, 28 Sep 2006 02:51:06 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSpdE-0007Fl-0E for ltru@ietf.org; Thu, 28 Sep 2006 02:44:29 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060928064424.MXCM5459.mta9.adelphia.net@DGBP7M81> for ; Thu, 28 Sep 2006 02:44:24 -0400 Message-ID: <007b01c6e2c9$8a48ab80$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Wed, 27 Sep 2006 23:44:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Subject: [Ltru] Pre-draft-00 for RFC 4645bis X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org 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. <> 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 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 03:38:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSqTd-0004CM-DT; Thu, 28 Sep 2006 03:38:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSqTc-0004CH-1Y for ltru@ietf.org; Thu, 28 Sep 2006 03:38:36 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSqTX-0001vR-1j for ltru@ietf.org; Thu, 28 Sep 2006 03:38:36 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004802934.msg for ; Thu, 28 Sep 2006 08:40:30 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 28 Sep 2006 08:38:43 +0100 From: "Debbie Garside" To: , "'Frank Ellermann'" Date: Thu, 28 Sep 2006 08:38:13 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcbihidULgyHgV3STeeiq+7ar5TMgQASm14g In-Reply-To: <30b660a20609271539pac3aa26w70e7e447b5981a9e@mail.gmail.com> Message-ID: <21525CFE44ED424C9238E17969C50B88.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Thu, 28 Sep 2006 08:40:30 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Thu, 28 Sep 2006 08:40:31 +0100 X-Spam-Score: 0.3 (/) X-Scan-Signature: b67ab81b2db0d00304056d0360a5a39a Cc: 'Michael Everson' , 'LTRU Working Group' , ietf-languages@alvestrand.no Subject: [Ltru] RE: frr, fy, ngo, tt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0467123514==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0467123514== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0482_01C6E2D9.70DDC300" This is a multi-part message in MIME format. ------=_NextPart_000_0482_01C6E2D9.70DDC300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mark =20 The following link will take you to the ISO 639-3 code list. The final letter in this link can be changed (a-z) to give you the corresponding languages in alphabetical order. This makes it very easy to check the = data - assuming the same name has been used.=20 =20 http://www.sil.org/iso639%2D3/codes.asp?order=3Dname &name=3Dname&letter=3Db =20 Best regards =20 Debbie _____ =20 From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of Mark Davis Sent: 27 September 2006 23:40 To: Frank Ellermann Cc: Michael Everson; LTRU Working Group; ietf-languages@alvestrand.no Subject: Re: frr, fy, ngo, tt If you are going to do any analysis of the differences, please take a = look also at my message of=20 From: Mark Davis Mailed-By: gmail.com=09 Subject: Re: Languages and Scripts which contained a listing of differences between the CLDR data and other Unicode data that we would like to reconcile. I repeat the data below.=20 In particular, I had asked on this list if anyone knew anything about = the couple of dozen purported languages at the end for which Magda couldn't = find 639-3 language codes. Hearing no response, we will probably just remove = them from the Unicode site as bogus.=20 [abq] ; Abaza ; [Cyrl] ; [ady] ; Adygei ; [Cyrl] ; [ain] ; Ainu ; [Kana]; [Latn] ; [amo] ; Amo ; [Latn] ; [av] ; Avar (Avaric?) ; [Cyrl] ; [awa] ; Awadhi ; [Deva] ; [ba] ; Bashkir ; [Cyrl] ;=20 [bbc] ; Batak toba ; [Batk]*; [Latn] ; [bfq] ; Badaga ; [Taml] ; [bft] ; Balti ; [Deva] ; [Removed Balti] [bfy] ; Bagheli ; [Deva] ; [bh] ; Bihari ; [Deva] ; [bhb] ; Bhili ; [Deva] ;=20 [bho] ; Bhojpuri ; [Deva] ; [bjj] ; Kanauji ; [Deva] ; [bku] ; Buhid ; [Buhd] ; [br] ; Breton ; [Latn] ; [bra] ; Braj bhasha ; [Deva] ; [btk] ; Batak ; [Batk]*, [Latn] ; [btv] ; Bateri (aka Bhatneri) ; [Deva] ;=20 [ccp] ; Chakma ; [Beng]; ; [Removed Chakma] [ce] ; Chechen ; [Cyrl] ; [chm] ; Mari ; [Cyrl]; [Latn] ; [cjs] ; Shor ; [Cyrl] ; [co] ; Corsican ; [Latn] ; [cop] ; Coptic ; [Arab]; [Copt] ; "[Added Grek, but is = that right now?]"=20 [cr] ; Cree ; [Cans]; [Latn] ; [cv] ; Chuvash ; [Cyrl] ; [dar] ; Dargwa ; [Cyrl] ; [en] ; English ; [Latn] ; "[Had Shavian and Deseret, but = those never had any significant usage]"=20 [evn] ; Evenki ; [Cyrl] ; [gag] ; Gagauz ; [Cyrl] ; [gbm] ; Garhwali ; [Deva] [gd] ; Gaelic ; [Latn] [gld] ; Nanai ; [Cyrl] [gon] ; Gondi ; [Deva]; [Telu] [grt] ; Garo ; [Beng]=20 [hmn] ; Hmong ; [Latn]; [Hmng]* [hnn] ; Hanun=F3o ; [Latn]; [Hano] [hoc] ; Ho ; [Deva] [hoj] ; Harauti ; [Deva] [hop] ; Hopi ; [Latn] [hy] ; Armenian ; [Armn]; [Syrc]* [ibb] ; Ibibio ; [Latn]=20 [id] ; Indonesian ; "[Arab]*, [Latn]" [ik] ; I=F1upiaq ; [Latn] [inh] ; Ingush ; [Arab]; [Latn] [jv] ; Javanese ; [Latn]; [Java]* [kaa] ; Karakalpak ; [Cyrl] [kac]? ; Kachchi ; [Deva]=20 [kbd] ; Kabardian ; [Cyrl] [kca] ; Khanty ; [Cyrl] [kdt] ; Kuy ; Thai [kha] ; Khasi ; [Latn]; [Beng] [kht] ; Khamti ; [Mymr] [kr] ; Kanuri ; [Latn] [krc] ; Karachay ; [Cyrl]=20 [krl] ; Karelian ; [Latn]; [Cyrl] [kv] ; Komi ; [Cyrl]; [Latn] [ky] ; Kirghiz ; [Arab]*; [Latn]; [Cyrl] [lad] ; Ladino ; [Hebr] [lbe] ; Lak ; [Cyrl] [lcp] ; "Lawa, western" ; Thai=20 [lep] ; Lepcha ; [Lepc]* [lez] ; Lezghian (Lezghi?) ; [Cyrl] [li]? ; Limbu ; [Deva]; [Limb] [lis] ; Lisu ; "Lisu (Fraser)*, [Latn]" [lmn] ; Lambadi ; [Telu] [lut] ; Lushootseed ; [Latn]=20 [lwl] ; "Lawa, eastern" ; Thai [mnc] ; Manchu ; [Mong] [mni] ; Meitei ; "Meetai Mayek*, [Beng]" [mns] ; Mansi ; [Cyrl] [mnw] ; Mon ; [Mymr] [muw] ; Mundari ; [Beng]; [Deva]=20 [mwr] ; Marwari ; [Deva] [nbf] ; Naxi ; Naxi* [new] ; Newari ; "[Deva]; Ranjana, Parachalit" [nog] ; Nogai ; [Cyrl] [nv] ; Navajo ; [Latn] [om] ; Oromo ; [Ethi]*; [Latn] ; "[According to wikipedia, Ethi = usage is old"=20 [os] ; Ossetic ; [Cyrl]; [Latn] ; [pi] ; Pali ; [Sinh]; [Deva]; [Thai] ; [prd] ; Parsi-dari ; [Arab] ; [prg] ; Prussian ; [Latn] ; [ro] ; Romanian ; [Latn]; [Cyrl]* ; [rom] ; Romany ; [Cyrl]; [Latn] ;=20 [sa] ; Sanskrit ; [Sinh]; [Deva]; etc. ; [CLDR doesn't do 'etc': = what is the exact list: all modern Indic scripts + Sinhala?] [sah] ; Yakut ; [Cyrl] ; [sat] ; Santali ; [Deva]; [Beng]; [Orya]; [Olck]* ;=20 [sel] ; Selkup ; [Cyrl] ; [shn] ; Shan ; [Mymr] ; [smi] ; Sami ; [Cyrl]; [Latn] ; [Is Cyrl common?] [smp] ; Samaritan ; [Hebr] ; [Removed Samaritan* [sn] ; Shona ; [Latn] ; [syl] ; Sylhetti ; [Sylo]; [Beng] ;=20 [tab] ; Tabasaran ; [Cyrl] ; [tbw] ; Tagbanwa ; [Latn]; ; [Removed Tagbanwa] [tcy] ; Tulu ; [Knda] ; [tl] ; Tagalog ; [Latn]; [Tglg] ; [It appears that Tglg is = not in modern use]=20 [tru] ; Turoyo ; [Syrc] ; [ttt] ; Tat ; [Cyrl] ; [tut] ; Altai (Altaic?) ; [Cyrl] ; [ty] ; Tahitian ; [Latn] ; [udm] ; Udmurt ; [Cyrl]; [Latn] ; [ug] ; Uighur ; [Arab]; [Latn]; [Cyrl] ; "[adds Latn, = Cyrl; is the=20 latter common? Removed Uighur]" [vi] ; Vietnamese ; [Latn]; Chu Nom ; [Chu Nom would be Hani*] [xal] ; Kalmyk ; [Cyrl] ; [xsr] ; Sherpa ; [Deva] ; [yrk] ; Nenets ; [Cyrl] ;=20 # Missing Language Codes ??? ; Aisor ; [Cyrl] ??? ; Assyrian (modern) ; [Syrc] ??? ; Bahasa ; [Latn] ??? ; Balear ; [Latn] ??? ; Balkar ; [Cyrl] ??? ; Bugis ; [Bugi]=20 ??? ; Buryat ; [Cyrl] ??? ; Cham ; [Cham]* ??? ; Chhattisgarhi ; [Deva] ??? ; Chukchi ; [Cyrl] ??? ; Dungan ; [Cyrl] ??? ; Edo ; [Latn] ??? ; Garshuni ; [Syrc]=20 ??? ; Gascon ; [Latn] ??? ; Judezmo ; [Hebr] ??? ; Kankan ; [Deva] ??? ; Khakass ; [Cyrl] ??? ; Koryak ; [Cyrl] ??? ; Lapp ; [Latn] ??? ; Mordvin ; [Cyrl]=20 ??? ; Naga ; [Latn]; [Beng] ??? ; Riang ; [Beng] ??? ; Swadaya ; [Syrc] ??? ; Tamazight ; [Tfng], [Latn] ??? ; Tsalagi ; (see Cherokee) ??? ; Tuva ; [Cyrl] ??? ; Udekhe ; [Cyrl]=20 On 9/27/06, Frank Ellermann wrote:=20 John Cowan wrote: > I'll post (some of) the current state of things shortly. Here's a list of 67 differences between LTRU and CLDR 1.4 Lines where LTRU has no script and CLDR more than one are most probably sane, but anything else should be checked:=20 lang aa ltru cldr Latn lang ak ltru cldr Latn lang az ltru cldr Arab Cyrl Latn lang bo ltru cldr Tibt lang cr ltru cldr Cans Latn lang ee ltru cldr Latn lang fy ltru cldr Latn=20 lang gd ltru cldr Latn lang ha ltru cldr Arab Latn lang ho ltru cldr Latn lang ia ltru cldr Latn lang ig ltru cldr Latn lang iu ltru cldr Cans Cyrl Latn lang ja ltru cldr Hani Hira Kana=20 lang ko ltru cldr Hang Hani lang ks ltru cldr Arab Deva lang ku ltru cldr Arab Cyrl Latn lang kw ltru cldr Latn lang ky ltru cldr Arab Cyrl lang mi ltru cldr Latn lang mn ltru cldr Cyrl Mong lang mo ltru Latn cldr Cyrl Latn lang ms ltru Latn cldr Arab Latn lang oc ltru cldr Latn lang os ltru cldr Latn lang pa ltru Guru cldr Arab Guru lang rm ltru cldr Latn=20 lang sa ltru cldr Deva lang sd ltru cldr Arab Deva lang se ltru cldr Latn lang sh ltru cldr Latn lang sr ltru cldr Cyrl Latn lang tg ltru cldr Arab Cyrl Latn lang tk ltru cldr Arab Cyrl Latn=20 lang tr ltru Latn cldr Arab Latn lang tt ltru cldr Cyrl lang ug ltru cldr Arab lang uz ltru cldr Arab Cyrl Latn lang yo ltru cldr Latn lang zh ltru cldr Bopo Hani Hans Hant=20 lang bal ltru cldr Arab Latn lang byn ltru cldr Ethi lang cch ltru cldr Latn lang chr ltru cldr Cher Latn lang cop ltru cldr Arab Copt lang fil ltru cldr Latn lang fiu ltru cldr Latn=20 lang fur ltru cldr Latn lang gaa ltru cldr Latn lang gez ltru cldr Ethi lang gsw ltru cldr Latn lang haw ltru cldr Latn lang kaj ltru cldr Latn lang kam ltru cldr Latn=20 lang kcg ltru cldr Latn lang kfo ltru cldr Latn lang kpe ltru cldr Latn lang sid ltru cldr Latn lang sma ltru cldr Latn lang smi ltru cldr Latn lang smj ltru cldr Latn=20 lang smn ltru cldr Latn lang sms ltru cldr Latn lang syr ltru cldr Syrc lang tet ltru cldr Latn lang tig ltru cldr Ethi lang wal ltru cldr Ethi _______________________________________________=20 Ietf-languages mailing list Ietf-languages@alvestrand.no http://www.alvestrand.no/mailman/listinfo/ietf-languages =20 ------=_NextPart_000_0482_01C6E2D9.70DDC300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Mark
 
The=20 following link will take you to the ISO 639-3 code list.  The final = letter=20 in this link can be changed (a-z) to give you the corresponding = languages=20 in alphabetical order.  This makes it very easy to check the data - = assuming the same name has been used. 
 
http://www.sil.org/iso639%2D3/codes.asp?order=3Dname&= amp;name=3Dname&letter=3Db
 
Best=20 regards
 
Debbie

From: = ietf-languages-bounces@alvestrand.no=20 [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of Mark = Davis
Sent: 27 September 2006 23:40
To: Frank=20 Ellermann
Cc: Michael Everson; LTRU Working Group;=20 ietf-languages@alvestrand.no
Subject: Re: frr, fy, ngo,=20 tt

If you are going to do any analysis of the differences, = please take=20 a look also at my message of

From: Mark Davis <mark.davis@icu-project.org= > Mailed-By: gmail.com

=
Subject: Re: Languages and = Scripts

which=20 contained a listing of differences between the CLDR data and other = Unicode=20 data that we would like to reconcile. I repeat the data below. =

In=20 particular, I had asked on this list if anyone knew anything about the = couple=20 of dozen purported languages at the end for which Magda couldn't find = 639-3=20 language codes. Hearing no response, we will probably just remove them = from=20 the Unicode site as bogus.

[abq] ; Abaza ; [Cyrl] ;
[ady] ; = Adygei=20 ;        [Cyrl] ;
[ain] ; Ainu ;  [Kana]; = [Latn]=20 ;
[amo] ; Amo ;   [Latn] ;
[av] ;  Avar (Avaric?) ; =  =20      [Cyrl] ;
[awa] ; Awadhi ;      =20  [Deva] ;
[ba] ;  Bashkir ;       [Cyrl] ; =
[bbc] ; Batak toba ;    [Batk]*; [Latn] ;
[bfq] ; = Badaga ;=20        [Taml] ;
[bft] ; Balti ; [Deva] ;   =  =20    [Removed Balti]
[bfy] ; Bagheli ;       = [Deva]=20 ;
[bh] ;  Bihari ;        [Deva] = ;
[bhb] ;=20 Bhili ; [Deva] ;
[bho] ; Bhojpuri ;      [Deva] = ;
[bjj]=20 ; Kanauji ;       [Deva] ;
[bku] ; Buhid ; [Buhd] = ;
[br]=20 ;  Breton ;        [Latn] ;
[bra] ; Braj = bhasha ;=20   [Deva] ;
[btk] ; Batak ; [Batk]*, [Latn] ;
[btv] ; Bateri = (aka=20 Bhatneri)  ;        [Deva] ;
[ccp] ; = Chakma ;=20        [Beng]; ;       [Removed=20 Chakma]
[ce] ;  Chechen ;       [Cyrl] = ;
[chm] ;=20 Mari ;  [Cyrl]; [Latn] ;
[cjs] ; Shor ;  [Cyrl] ;
[co] = ;=20  Corsican ;      [Latn] ;
[cop] ; Coptic ; =  =20      [Arab]; [Copt] ;       =  "[Added Grek,=20 but is that right now?]"
[cr] ;  Cree ;  [Cans]; [Latn]=20 ;
[cv] ;  Chuvash ;       [Cyrl] ;
[dar] ; = Dargwa ;=20        [Cyrl] ;
[en] ;  English ;   =  =20   [Latn] ;        "[Had Shavian and Deseret, = but=20 those never
had any significant usage]"
[evn] ; Evenki ;   =  =20    [Cyrl] ;
[gag] ; Gagauz ;       =  [Cyrl]=20 ;
[gbm] ; Garhwali ;      [Deva]
[gd] ; =  Gaelic ;=20        [Latn]
[gld] ; Nanai ; [Cyrl]
[gon] ; = Gondi ;=20 [Deva]; [Telu]
[grt] ; Garo ;  [Beng]
[hmn] ; Hmong ; = [Latn];=20 [Hmng]*
[hnn] ; Hanun=F3o ;       [Latn]; = [Hano]
[hoc] ; Ho=20 ;    [Deva]
[hoj] ; Harauti ;      =20 [Deva]
[hop] ; Hopi ;  [Latn]
[hy] ;  Armenian ; =    =20  [Armn]; [Syrc]*
[ibb] ; Ibibio ;       =  [Latn]=20
[id] ;  Indonesian ;    "[Arab]*, [Latn]"
[ik] ; =  I=F1upiaq ;       [Latn]
[inh] ; Ingush ; =    =20    [Arab]; [Latn]
[jv] ;  Javanese ;    =20  [Latn]; [Java]*
[kaa] ; Karakalpak ;   =  [Cyrl]
[kac]? ;=20        Kachchi ;       [Deva] =
[kbd] ;=20 Kabardian ;     [Cyrl]
[kca] ; Khanty ;     =  =20  [Cyrl]
[kdt] ; Kuy ;   Thai
[kha] ; Khasi ; [Latn];=20 [Beng]
[kht] ; Khamti ;        [Mymr]
[kr] ; =  Kanuri ;        [Latn]
[krc] ; Karachay ; =  =20    [Cyrl]
[krl] ; Karelian ;      [Latn]; = [Cyrl]
[kv] ;  Komi ;  [Cyrl]; [Latn]
[ky] ; =  Kirghiz ;=20       [Arab]*; [Latn]; [Cyrl]
[lad] ; Ladino ; =    =20    [Hebr]
[lbe] ; Lak ;   [Cyrl]
[lcp] ; "Lawa, = western"=20 ;       Thai
[lep] ; Lepcha ;      =20  [Lepc]*
[lez] ; Lezghian (Lezghi?) ;   =  [Cyrl]
[li]? ;=20 Limbu ; [Deva]; [Limb]
[lis] ; Lisu ;  "Lisu (Fraser)*,=20 [Latn]"
[lmn] ; Lambadi ;       [Telu]
[lut] ;=20 Lushootseed ;   [Latn]
[lwl] ; "Lawa, eastern" ;   =    =20 Thai
[mnc] ; Manchu ;        [Mong]
[mni] ; = Meitei ;=20        "Meetai Mayek*, [Beng]"
[mns] ; Mansi ;=20 [Cyrl]
[mnw] ; Mon ;   [Mymr]
[muw] ; Mundari ;   =  =20   [Beng]; [Deva]
[mwr] ; Marwari ;      =20 [Deva]
[nbf] ; Naxi ;  Naxi*
[new] ; Newari ;     =  =20  "[Deva]; Ranjana, Parachalit"
[nog] ; Nogai ; [Cyrl]
[nv] = ;=20  Navajo ;        [Latn]
[om] ;  Oromo = ;=20 [Ethi]*; [Latn] ;       "[According to wikipedia, Ethi = usage is=20 old"
[os] ;  Ossetic ;       [Cyrl]; [Latn] = ;
[pi]=20 ;  Pali ;  [Sinh]; [Deva]; [Thai] ;
[prd] ; Parsi-dari ; =  =20  [Arab] ;
[prg] ; Prussian ;      [Latn] = ;
[ro] ;=20  Romanian ;      [Latn]; [Cyrl]* ;
[rom] ; = Romany ;=20        [Cyrl]; [Latn] ;
[sa] ;  Sanskrit = ;  =20    [Sinh]; [Deva]; etc. ;  [CLDR doesn't do 'etc': = what
is=20 the exact list: all modern Indic scripts + Sinhala?]
[sah] ; Yakut = ; [Cyrl]=20 ;
[sat] ; Santali ;       [Deva]; [Beng]; [Orya]; = [Olck]* ;=20
[sel] ; Selkup ;        [Cyrl] ;
[shn] ; = Shan ;=20  [Mymr] ;
[smi] ; Sami ;  [Cyrl]; [Latn] ;     =  =20  [Is Cyrl common?]
[smp] ; Samaritan ;     [Hebr] ; =  =20      [Removed Samaritan*
[sn] ;  Shona ; [Latn] = ;
[syl] ; Sylhetti ;      [Sylo]; [Beng] ;
[tab] = ;=20 Tabasaran ;     [Cyrl] ;
[tbw] ; Tagbanwa ;     =  [Latn];  ;      [Removed Tagbanwa]
[tcy] = ; Tulu ;=20  [Knda] ;
[tl] ;  Tagalog ;       [Latn]; = [Tglg] ;=20        [It appears that Tglg is not in modern use] =
[tru] ; Turoyo ;        [Syrc] ;
[ttt] ; = Tat ;=20   [Cyrl] ;
[tut] ; Altai (Altaic?) ;       = [Cyrl]=20 ;
[ty] ;  Tahitian ;      [Latn] ;
[udm] ; = Udmurt ;=20        [Cyrl]; [Latn] ;
[ug] ;  Uighur ; =  =20      [Arab]; [Latn]; [Cyrl] ;       =  "[adds=20 Latn, Cyrl; is the
latter common?  Removed Uighur]"
[vi] ; =  Vietnamese ;    [Latn]; Chu Nom ;       = [Chu=20 Nom would be Hani*]
[xal] ; Kalmyk ;       =  [Cyrl]=20 ;
[xsr] ; Sherpa ;        [Deva] ;
[yrk] ; = Nenets ;=20        [Cyrl] ;

# Missing Language=20 Codes

??? ;   Aisor ; [Cyrl]
??? ;   Assyrian = (modern) ;=20     [Syrc]
??? ;   Bahasa ;      =20  [Latn]
??? ;   Balear ;       =  [Latn]
???=20 ;   Balkar ;        [Cyrl]
??? ;   = Bugis ;=20 [Bugi]
??? ;   Buryat ;       =  [Cyrl]
??? ;=20   Cham ;  [Cham]*
??? ;   Chhattisgarhi ; = [Deva]
??? ;=20   Chukchi ;       [Cyrl]
??? ;   Dungan ; =  =20      [Cyrl]
??? ;   Edo ;   [Latn]
??? = ;  =20 Garshuni ;      [Syrc]
??? ;   Gascon ;   =  =20    [Latn]
??? ;   Judezmo ;      =20 [Hebr]
??? ;   Kankan ;       =  [Deva]
??? ;=20   Khakass ;       [Cyrl]
??? ;   Koryak ; =  =20      [Cyrl]
??? ;   Lapp ;  [Latn]
??? = ;  =20 Mordvin ;       [Cyrl]
??? ;   Naga ; =  [Latn];=20 [Beng]
??? ;   Riang ; [Beng]
??? ;   Swadaya ;   =  =20   [Syrc]
??? ;   Tamazight ;     [Tfng], = [Latn]
???=20 ;   Tsalagi ;       (see Cherokee)
??? ;   = Tuva ;=20  [Cyrl]
??? ;   Udekhe ;       =  [Cyrl]=20

On 9/27/06, Frank=20 Ellermann <nobody@xyzzy.claranet.de>= =20 wrote:
John=20 Cowan wrote:

> I'll post (some of) the current state of = things=20 shortly.

Here's a list of 67 differences between LTRU and = CLDR=20 1.4

Lines where LTRU has no script and CLDR more than one = are
most=20 probably sane, but anything else should be checked:

lang=20 aa  ltru      cldr = Latn
lang=20 ak  ltru      cldr = Latn
lang=20 az  ltru      cldr Arab Cyrl = Latn
lang = bo  ltru      cldr=20 Tibt
lang = cr  ltru      cldr Cans=20 Latn
lang = ee  ltru      cldr=20 Latn
lang = fy  ltru      cldr Latn=20
lang gd  ltru      cldr=20 Latn
lang = ha  ltru      cldr Arab=20 Latn
lang = ho  ltru      cldr=20 Latn
lang = ia  ltru      cldr=20 Latn
lang = ig  ltru      cldr=20 Latn
lang = iu  ltru      cldr Cans=20 Cyrl Latn
lang = ja  ltru      cldr=20 Hani Hira Kana
lang=20 ko  ltru      cldr Hang = Hani
lang=20 ks  ltru      cldr Arab = Deva
lang=20 ku  ltru      cldr Arab Cyrl = Latn
lang = kw  ltru      cldr=20 Latn
lang = ky  ltru      cldr Arab=20 Cyrl
lang = mi  ltru      cldr=20 Latn
lang = mn  ltru      cldr Cyrl=20 Mong
lang mo  ltru Latn cldr Cyrl Latn
lang=20 ms  ltru Latn cldr Arab Latn
lang=20 oc  ltru      cldr = Latn
lang=20 os  ltru      cldr = Latn
lang=20 pa  ltru Guru cldr Arab Guru
lang=20 rm  ltru      cldr Latn =
lang=20 sa  ltru      cldr = Deva
lang=20 sd  ltru      cldr Arab = Deva
lang=20 se  ltru      cldr = Latn
lang=20 sh  ltru      cldr = Latn
lang=20 sr  ltru      cldr Cyrl = Latn
lang=20 tg  ltru      cldr Arab Cyrl = Latn
lang = tk  ltru      cldr Arab=20 Cyrl Latn
lang tr  ltru Latn cldr Arab Latn
lang=20 tt  ltru      cldr = Cyrl
lang=20 ug  ltru      cldr = Arab
lang=20 uz  ltru      cldr Arab Cyrl = Latn
lang = yo  ltru      cldr=20 Latn
lang = zh  ltru      cldr Bopo=20 Hani Hans Hant
lang bal = ltru      cldr=20 Arab Latn
lang byn ltru      cldr=20 Ethi
lang cch ltru      cldr = Latn
lang=20 chr ltru      cldr Cher Latn
lang = cop=20 ltru      cldr Arab Copt
lang fil=20 ltru      cldr Latn
lang fiu=20 ltru      cldr Latn
lang fur=20 ltru      cldr Latn
lang gaa=20 ltru      cldr Latn
lang gez=20 ltru      cldr Ethi
lang gsw=20 ltru      cldr Latn
lang haw=20 ltru      cldr Latn
lang kaj=20 ltru      cldr Latn
lang kam=20 ltru      cldr Latn
lang kcg=20 ltru      cldr Latn
lang kfo=20 ltru      cldr Latn
lang kpe=20 ltru      cldr Latn
lang sid=20 ltru      cldr Latn
lang sma=20 ltru      cldr Latn
lang smi=20 ltru      cldr Latn
lang smj=20 ltru      cldr Latn
lang smn=20 ltru      cldr Latn
lang sms=20 ltru      cldr Latn
lang syr=20 ltru      cldr Syrc
lang tet=20 ltru      cldr Latn
lang tig=20 ltru      cldr Ethi
lang wal=20 ltru      cldr=20 Ethi


_______________________________________________=20
Ietf-languages mailing list
Ietf-languages@alvestrand.no=
http://= www.alvestrand.no/mailman/listinfo/ietf-languages=20

------=_NextPart_000_0482_01C6E2D9.70DDC300-- --===============0467123514== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0467123514==-- From ltru-bounces@ietf.org Thu Sep 28 06:30:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSt9R-0001Y4-VX; Thu, 28 Sep 2006 06:29:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSs8k-0006Mo-2p for ltru@ietf.org; Thu, 28 Sep 2006 05:25:10 -0400 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSs8i-0008Ee-NK for ltru@ietf.org; Thu, 28 Sep 2006 05:25:10 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 09ADF4632; Thu, 28 Sep 2006 18:24:50 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12843-08; Thu, 28 Sep 2006 18:24:49 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp (toro [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id BEA68445A; Thu, 28 Sep 2006 18:24:49 +0900 (JST) Date: Thu, 28 Sep 2006 18:24:49 +0900 Message-ID: From: Masayasu Ishikawa To: Martin Duerst Organization: W3C - World Wide Web Consortium In-Reply-To: <6.0.0.20.2.20060928133744.04e41840@localhost> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Thu, 28 Sep 2006 06:29:57 -0400 Cc: ietf-languages@iana.org, LTRU Working Group Subject: [Ltru] Re: Korean (and Japanese) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > Speaking about Japanese, I'm quite surprised that we don't have > Supress-script: Jpan > at > Type: language > Subtag: ja > Description: Japanese > Added: 2005-10-16 > When something is tagged ja, the assumption is that it's written in > Kanji-Kana mixture, because that's how Japanese is written. In many cases yes, but you can find quite a few exceptions. For example, "Ishikawa" in romaji is Japanese, even if it is written in Latin script, and I used the language tag "ja" in quite a few places for that. With RFC 4646 I could use "ja-Latn" in that case, but anyway, there's more than one way to write Japanese and I wouldn't simply assume that "ja" means "written in Kanji-Kana mixture". -- Masayasu Ishikawa _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 06:43:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GStMA-0000Po-2y; Thu, 28 Sep 2006 06:43:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GStM9-0000Pj-6z for ltru@ietf.org; Thu, 28 Sep 2006 06:43:05 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GStM6-0005QZ-BZ for ltru@ietf.org; Thu, 28 Sep 2006 06:43:05 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8SAgkh3012090 for ; Thu, 28 Sep 2006 19:42:48 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 1d21_14177c26_4ede_11db_8c00_0014221f2a2d; Thu, 28 Sep 2006 19:42:46 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:48886) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 28 Sep 2006 19:42:43 +0900 Message-Id: <6.0.0.20.2.20060928193237.08122670@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 28 Sep 2006 19:42:16 +0900 To: Masayasu Ishikawa From: Martin Duerst In-Reply-To: References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ietf-languages@iana.org, LTRU Working Group Subject: [Ltru] Re: Korean (and Japanese) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Masayasu, At 18:24 06/09/28, Masayasu Ishikawa wrote: >Martin Duerst wrote: > >> Speaking about Japanese, I'm quite surprised that we don't have >> Supress-script: Jpan >> at >> Type: language >> Subtag: ja >> Description: Japanese >> Added: 2005-10-16 >> When something is tagged ja, the assumption is that it's written in >> Kanji-Kana mixture, because that's how Japanese is written. > >In many cases yes, but you can find quite a few exceptions. >For example, "Ishikawa" in romaji is Japanese, even if it is >written in Latin script, and I used the language tag "ja" in >quite a few places for that. With RFC 4646 I could use "ja-Latn" >in that case, but anyway, there's more than one way to write >Japanese and I wouldn't simply assume that "ja" means "written >in Kanji-Kana mixture". I guess this makes sense. But my guess is that this is on a micro level. On that level, the main usages of the information are e.g. for text-to-speach. What you want is that your name is pronounced in the Japanese way rather than the way an English (or some other language) speaker would pronounce it. The characters are there in the data, so tagging the script would actually be overkill, either redundant or contradictory. I think this is an interesting aspect of language tagging that maybe we should mention in the RFC 4646bis: The script can be left out if it's obvious from the data. This would just be a special case of John's "tag wisely" general principle. This in my view doesn't justify to not use Jpan as a supress- script, but it gives you the licence to just use ja even if ja-Latn would be more precise. I think the main use case for suppress-script is for things such as whole-document search: You don't want to have to look into each document to check what script(s) it uses. In that case, to me the only reasonable way for things to work is that ja means "Japanese, as usually written (Kanji-Kana mixture), and ja-Latn is used for romanized documents (except for learning material, and some stuff in the early years of computer use, I haven't seen a single ja-Latn document, and I look at Japanese all day). Would you agree with this analysis? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 08:07:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSufn-0005gJ-Dr; Thu, 28 Sep 2006 08:07:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSufl-0005gD-Om for ltru@ietf.org; Thu, 28 Sep 2006 08:07:25 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSufh-00010i-GP for ltru@ietf.org; Thu, 28 Sep 2006 08:07:25 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 43DB5240814; Thu, 28 Sep 2006 14:07:01 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 8D86E129CE; Thu, 28 Sep 2006 14:06:36 +0200 (CEST) Date: Thu, 28 Sep 2006 14:06:36 +0200 From: Stephane Bortzmeyer To: ltru@ietf.org Message-ID: <20060928120636.GA14607@sources.org> References: <451B4901.3D41@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ltru] Re: ISO/IEC 10646 and ISO/IEC 14651 freely available X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On the ietf-languages mailing list, I learned that some ISO standards are available online: http://standards.iso.org/ittf/PubliclyAvailableStandards/ One which is interesting to us is 5218 "Codes for the representation of human sexes" which normalizes: Data elements Code Not known 0 (zero) Male 1 (one) Female 2 (two) Not applicable 9 (nine) It is a shame we cannot encode this information in language tags. I suggest, for RFC 4646bis to add: sex = 1DIGIT ; ISO 5218 code so we accept fr-1 to mean "french spoken by a man" or zh-2 (chinese as spoken by a woman). It is strange that Jefsey Morfin did not propose this already. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 09:00:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSvVM-0002IT-VC; Thu, 28 Sep 2006 09:00:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSvVL-0002IJ-PF for ltru@ietf.org; Thu, 28 Sep 2006 09:00:43 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSvVK-0002eP-Gg for ltru@ietf.org; Thu, 28 Sep 2006 09:00:43 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060928130037.EZJ28964.mta10.adelphia.net@DGBP7M81>; Thu, 28 Sep 2006 09:00:37 -0400 Message-ID: <00a801c6e2fe$183e8980$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" , References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> Date: Thu, 28 Sep 2006 06:00:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: Korean (and Japanese) (was: Re: Suppress-Script batch 1) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > Speaking about Japanese, I'm quite surprised that we don't have > Supress-script: Jpan > at > Type: language > Subtag: ja > Description: Japanese > Added: 2005-10-16 That's easy: Jpan was added to ISO 15924 this past July, after we went through our first round of adding Suppress-Scripts in bulk, and nobody thought to add it to ja. -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 09:08:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSvd4-00062F-4Z; Thu, 28 Sep 2006 09:08:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSvd2-00061f-R3 for ltru@ietf.org; Thu, 28 Sep 2006 09:08:40 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSvd1-00044G-Gd for ltru@ietf.org; Thu, 28 Sep 2006 09:08:40 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060928130838.LDPV437.mta13.adelphia.net@DGBP7M81> for ; Thu, 28 Sep 2006 09:08:38 -0400 Message-ID: <00aa01c6e2ff$372a8870$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 28 Sep 2006 06:08:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ltru] Re: Suppress-Script batch 1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> it needs to be confirmed that such a request relates to >> actual usage, and is not a "test" of the system or an >> attempt to "prove" something about the system or its >> participants or related SDOs. > > 1: The intended cleanup of the missing Suppress-Scripts did > not work so far. I think it safe to say there are signficant differences of opinion about what it means to "clean these up." > 2: What's okay for ngo should be also okay for fy and frr. I see your point that it was inconsistent to say we should only add Suppress-Script for language subtags that existed under RFC 3066, and then to add it for the new subtag 'nqo' in June. > 3: I consider statements that my registration request for > frr was a bad faith effort as insulting. It's certainly not as bad as proposing a subtag to try to demonstrate a conflict between this group and SDOs or other groups (especially when such a conflict doesn't exist). As it turns out, we have had ample oppotrunity over the past year to make a variety of changes to the Registry, so there is no longer a need to "test the system" -- it's been tested and some of the "opportunities for improvement" have become apparent. -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 09:45:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSwCW-00033T-TP; Thu, 28 Sep 2006 09:45:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSwCV-00033N-SL for ltru@ietf.org; Thu, 28 Sep 2006 09:45:19 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSwCT-00006K-JR for ltru@ietf.org; Thu, 28 Sep 2006 09:45:19 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060928134516.JVIX8494.mta9.adelphia.net@DGBP7M81> for ; Thu, 28 Sep 2006 09:45:16 -0400 Message-ID: <00cc01c6e304$5552c560$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Thu, 28 Sep 2006 06:45:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Ltru] UK redux (was: Re: langauge vs. locale) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Marion Gunn wrote: >>> -- otherwise one couldn't distinguish between en-US and en-UK >>> content. >> >> en-GB > > Explain that to people in my country with addresses ending in uk.:-( > > (Not really asking Doug to explain, only praying for him to come over > to the side of the light.) Whether or not I personally agree that UK should be the ISO 3166-1 code element for the United Kingdom is not the point. We use *assigned* code elements, past and present, from ISO 3166-1 as region subtags. We do not use their exceptionally reserved, transitionally reserved, indeterminately reserved, or otherwise unused code elements, except those that were *assigned* to a country name at some point since 1988. This is a simple rule that avoids most accusations of arbitrary or discriminatory "cherry-picking." When ISO 3166/MA decides to assign -- not "reserve" -- UK as a code element, I will be happy to support adding it to the Registry, in accordance with the rules. The same goes for any other pair of letters. -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 17:43:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT3es-0002h6-VA; Thu, 28 Sep 2006 17:43:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT3er-0002gv-RX for ltru@ietf.org; Thu, 28 Sep 2006 17:43:05 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT3eo-0005qw-HB for ltru@ietf.org; Thu, 28 Sep 2006 17:43:05 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B80C52596D1; Thu, 28 Sep 2006 23:40:38 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20668-07; Thu, 28 Sep 2006 23:40:33 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9FC542596BA; Thu, 28 Sep 2006 23:40:33 +0200 (CEST) Message-ID: <451C41E0.60009@alvestrand.no> Date: Thu, 28 Sep 2006 23:42:56 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: ietf-languages@iana.org References: <002f01c6e274$1704ebc0$6500a8c0@chalmers95a69n> <30b660a20609271816k4d291bf8wce083d369aedabd9@mail.gmail.com> <7.0.1.0.2.20060928113516.03c35d58@dirsafe.com> In-Reply-To: <7.0.1.0.2.20060928113516.03c35d58@dirsafe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org Subject: [Ltru] ADMIN: Enforcement of suspension of posting rights (Re: langauge vs. locale) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org As a routine matter, the new address of Jefsey Morfin has been blocked from posting on the list. Harald, listadmin Wentry System wrote: > > I copy this important exchange with my premiminary note to most of the > people I know who are interested in the language diversity issue. This > is a long post. However the exchange is between the two certainly most > competent and key persons in the area and deals with the most > important point for language digital support. > All the best. > jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 19:47:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT5bU-0006gm-EL; Thu, 28 Sep 2006 19:47:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT5bT-0006gh-6U for ltru@lists.ietf.org; Thu, 28 Sep 2006 19:47:43 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT5bR-0003gT-QU for ltru@lists.ietf.org; Thu, 28 Sep 2006 19:47:43 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GT5b1-00052r-1g for ltru@lists.ietf.org; Fri, 29 Sep 2006 01:47:16 +0200 Received: from pd9fba8d8.dip0.t-ipconnect.de ([217.251.168.216]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Sep 2006 01:47:15 +0200 Received: from nobody by pd9fba8d8.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Sep 2006 01:47:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 29 Sep 2006 01:46:01 +0200 Organization: Lines: 9 Message-ID: <451C5EB9.725F@xyzzy.claranet.de> References: <451B4901.3D41@xyzzy.claranet.de> <20060928120636.GA14607@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8d8.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Ltru] OT: ISO/IEC 10646 and ISO/IEC 14651 freely available X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > fr-1 to mean "french spoken by a man" or zh-2 (chinese as > spoken by a woman). That could get extension "s", extension "l" is for locations, en-scouse-l-airport = "Scouse as spoken on airports". Joke off, no issue, 4646 requires "IETF consensus" for extensions. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 20:21:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT68R-0004l3-9n; Thu, 28 Sep 2006 20:21:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT68P-0004ky-Th for ltru@lists.ietf.org; Thu, 28 Sep 2006 20:21:45 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT68O-0008Ar-Jl for ltru@lists.ietf.org; Thu, 28 Sep 2006 20:21:45 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GT67r-0005J3-6P for ltru@lists.ietf.org; Fri, 29 Sep 2006 02:21:11 +0200 Received: from pd9fba8d8.dip0.t-ipconnect.de ([217.251.168.216]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Sep 2006 02:21:11 +0200 Received: from nobody by pd9fba8d8.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Sep 2006 02:21:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 29 Sep 2006 02:19:47 +0200 Organization: Lines: 28 Message-ID: <451C66A3.52C9@xyzzy.claranet.de> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> <6.0.0.20.2.20060928193237.08122670__32691.3689300001$1159440247$gmane$org@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8d8.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Ltru] Re: Korean (and Japanese) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > an interesting aspect of language tagging that maybe we > should mention in the RFC 4646bis: The script can be left > out if it's obvious from the data. I don't get this, "language tagging is unnecessary if the language is obvious from the data" would be a very similar statement. What's "obvious" about a script in the age of Unicode ? Of course the script should be left out if it's irrelevant (spoken content), but that's another case. > This in my view doesn't justify to not use Jpan as a > supress-script, but it gives you the licence to just use > ja even if ja-Latn would be more precise. Legacy applications and content don't need a licence, they couldn't use ja-Latn before it was specified. And they'll continue to use ja until they are upgraded to 4646 or its successor(s), that could take decades (plural). All new applications better use a tag ja-Latn where that's relevant. And the same new applications need a licence to suppress Jpan in ja-Jpan for backwards compatibility, they need your proposed Suppress-Script. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 21:25:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT77a-0001NC-TR; Thu, 28 Sep 2006 21:24:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT77Z-0001K4-9j for ltru@lists.ietf.org; Thu, 28 Sep 2006 21:24:57 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT77W-0006tN-MY for ltru@lists.ietf.org; Thu, 28 Sep 2006 21:24:57 -0400 Received: by nf-out-0910.google.com with SMTP id n15so928104nfc for ; Thu, 28 Sep 2006 18:24:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=uhJUUCf9neB+VMpwOrWUj8/ArwakiMFpJitgncl3zkI38o+QWGFo9cBdww9E1wCd8yRodoxHNMbh335nAywXiFwoB66cwNdrGztoDD9TIFXiC0xoeDnPcKdF0s4N8wvOUi0YdOquIvmtU3wfIXqh8Tmn4xNlKfs8HbZSgF0obwI= Received: by 10.48.210.20 with SMTP id i20mr4416814nfg; Thu, 28 Sep 2006 18:24:53 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Thu, 28 Sep 2006 18:24:53 -0700 (PDT) Message-ID: <30b660a20609281824m560066c0k1202af61d673e724@mail.gmail.com> Date: Thu, 28 Sep 2006 18:24:53 -0700 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: Korean (and Japanese) In-Reply-To: <451C66A3.52C9@xyzzy.claranet.de> MIME-Version: 1.0 References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> <6.0.0.20.2.20060928193237.08122670__32691.3689300001$1159440247$gmane$org@localhost> <451C66A3.52C9@xyzzy.claranet.de> X-Google-Sender-Auth: 250ab7cca2712bd5 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1677978725==" Errors-To: ltru-bounces@ietf.org --===============1677978725== Content-Type: multipart/alternative; boundary="----=_Part_341_12659825.1159493093633" ------=_Part_341_12659825.1159493093633 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline WW91J3JlIHJlYWRpbmcgaW50byB0aGUgc3BlYyBydWxlcyB0aGF0IGRvbid0IGV4aXN0OyBTdXBw cmVzcy1TY3JpcHQgaXMgYQpTSE9VTEQgbm90IGEgTVVTVC4gSXQgaXMgcGVyZmVjdGx5IHZhbGlk IC0tIGFuZCByZWFzb25hYmxlIC0tIGZvciBtZSB0byB0YWcKYXMgZm9sbG93czoKCkEuICo8Ymxh aCB4bWw6bGFuZz0namEnPmthbmppKgoo5ryi5a2XPGh0dHA6Ly9lbi53aWt0aW9uYXJ5Lm9yZy93 aWtpLyVFNiVCQyVBMiVFNSVBRCU5Nz4KKTwvYmxhaD4KCkkgZG9uJ3QgKmhhdmUqIHRvIGluZGlj YXRlIHRoZSBzY3JpcHQuIE5vdywgSSBjb3VsZCBhbHNvIGNvcnJlY3RseSB0YWcgYXM6CgoqQi4g PGJsYWggeG1sOmxhbmc9J2phLUxhdG4nPmthbmppKjwvYmxhaD48YmxhaCAqeG1sOmxhbmc9J2ph LUphcG4nKj4KKOa8ouWtlzxodHRwOi8vZW4ud2lrdGlvbmFyeS5vcmcvd2lraS8lRTYlQkMlQTIl RTUlQUQlOTc+Cik8L2JsYWg+CipDLiA8YmxhaCB4bWw6bGFuZz0namEnPmthbmppKjwvYmxhaD48 YmxhaCAqeG1sOmxhbmc9J2phLUphcG4nKj4KKOa8ouWtlzxodHRwOi8vZW4ud2lrdGlvbmFyeS5v cmcvd2lraS8lRTYlQkMlQTIlRTUlQUQlOTc+Cik8L2JsYWg+CipELiA8YmxhaCB4bWw6bGFuZz0n amEtTGF0bic+a2FuamkqPC9ibGFoPjxibGFoICp4bWw6bGFuZz0namEnKj4KKOa8ouWtlzxodHRw Oi8vZW4ud2lrdGlvbmFyeS5vcmcvd2lraS8lRTYlQkMlQTIlRTUlQUQlOTc+Cik8L2JsYWg+CgpB bmQgb2YgY291cnNlLCBJIGNvdWxkIGluY29ycmVjdGx5IHRhZyBhcyB0aGUgZm9sbG93aW5nLCBv ciBvdGhlciBpbnZhbGlkCnZhcmlhbnRzOgoqRS4gPGJsYWggeG1sOmxhbmc9J2phLUphcG4nPmth bmppKgoo5ryi5a2XPGh0dHA6Ly9lbi53aWt0aW9uYXJ5Lm9yZy93aWtpLyVFNiVCQyVBMiVFNSVB RCU5Nz4KKTwvYmxhaD4KRi4gKjxibGFoIHhtbDpsYW5nPSdqYS1MYXRuJz5rYW5qaSoKKOa8ouWt lzxodHRwOi8vZW4ud2lrdGlvbmFyeS5vcmcvd2lraS8lRTYlQkMlQTIlRTUlQUQlOTc+Cik8L2Js YWg+CgpXaGF0IE1hcnRpbiB3YXMgcG9pbnRpbmcgb3V0IGlzIHRoYXQgaW4gc2l0dWF0aW9ucyBs aWtlIHRoaXMsIEkgY2FuCmV4dGVybmFsbHkgdmVyaWZ5IHByb2dyYW1tYXRpY2FsbHkgdGhhdCBF IGFuZCBGIGFyZSBpbmNvcnJlY3Q7IGxpYnJhcmllcwp0aGF0IHVzZSB0aGUgVW5pY29kZSBDaGFy YWN0ZXIgRGF0YWJhc2UgKGxpa2UgSUNVIGFuZCBvdGhlcnMpIGNhbiBkZXRlcm1pbmUKdGhhdCB0 aGVyZSBhcmUgY2hhcmFjdGVycyBpbiB0aGUgc3BhbiB0aGF0IGFyZSBub3QgSmFwbiBhbmQgdGhl cmUgYXJlCmNoYXJhY3RlcnMgaW4gRiB0aGF0IGFyZSBub3QgTGF0bi4gSW4gc3VjaCBjaXJjdW1z dGFuY2VzLCBJIGRvbid0IG5lZWQgdG8Kc3VwcGx5IHRoZSBzY3JpcHQuIFtTY3JpcHQgdmFyaWFu dHMgYXJlIGEgZGlmZmVyZW50IG1hdHRlcjsgSGFudCBhbmQgSGFucwpvdmVybGFwOiBzb21lIGNo YXJhY3RlcnMgYXJlIGNsZWFybHkgb25seSBIYW50IGFuZCBzb21lIGNsZWFybHkgb25seSBIYW5z LApidXQgbWFueSBhcmUgc2hhcmVkLiAoVGhlcmUgYXJlIG90aGVyIGlzc3VlcyB3aXRoIHRoZXNl IHRoYXQgSSB3b24ndCBnbwppbnRvKS5dCgpNb3Jlb3Zlciwgd2hlbiBJIHNhaWQgKmluY29ycmVj dCosIGl0IGlzIG5vdCwgb2YgY291cnNlLCBhIGNvbmZvcm1hbmNlCmlzc3VlLiBUaGVyZSBpcyBu b3RoaW5nIGluIFJGQyA0NjQ2IHRoYXQgcmVxdWlyZXMgdGhhdCBhbnkgcGFydGljdWxhciB0ZXh0 CmJlIGNvcnJlY3RseSB0YWdnZWQuIFRoZSBvbmx5IHRoaW5nIHRoZSBSRkMgY2FuIGRvIGRldGVy bWluZSB0aGUgbWVhbmluZyBvZgonamEtSmFwbicsIG5vdCBpdHMgY29ycmVjdCBhcHBsaWNhdGlv bi4KCk1hcmsKCk9uIDkvMjgvMDYsIEZyYW5rIEVsbGVybWFubiA8bm9ib2R5QHh5enp5LmNsYXJh bmV0LmRlPiB3cm90ZToKPgo+IE1hcnRpbiBEdWVyc3Qgd3JvdGU6Cj4KPiA+IGFuIGludGVyZXN0 aW5nIGFzcGVjdCBvZiBsYW5ndWFnZSB0YWdnaW5nIHRoYXQgbWF5YmUgd2UKPiA+IHNob3VsZCBt ZW50aW9uIGluIHRoZSBSRkMgNDY0NmJpczogVGhlIHNjcmlwdCBjYW4gYmUgbGVmdAo+ID4gb3V0 IGlmIGl0J3Mgb2J2aW91cyBmcm9tIHRoZSBkYXRhLgo+Cj4gSSBkb24ndCBnZXQgdGhpcywgImxh bmd1YWdlIHRhZ2dpbmcgaXMgdW5uZWNlc3NhcnkgaWYgdGhlCj4gbGFuZ3VhZ2UgaXMgb2J2aW91 cyBmcm9tIHRoZSBkYXRhIiB3b3VsZCBiZSBhIHZlcnkgc2ltaWxhcgo+IHN0YXRlbWVudC4gIFdo YXQncyAib2J2aW91cyIgYWJvdXQgYSBzY3JpcHQgaW4gdGhlIGFnZSBvZgo+IFVuaWNvZGUgPyAg T2YgY291cnNlIHRoZSBzY3JpcHQgc2hvdWxkIGJlIGxlZnQgb3V0IGlmIGl0J3MKPiBpcnJlbGV2 YW50IChzcG9rZW4gY29udGVudCksIGJ1dCB0aGF0J3MgYW5vdGhlciBjYXNlLgo+Cj4gPiBUaGlz IGluIG15IHZpZXcgZG9lc24ndCBqdXN0aWZ5IHRvIG5vdCB1c2UgSnBhbiBhcyBhCj4gPiBzdXBy ZXNzLXNjcmlwdCwgYnV0IGl0IGdpdmVzIHlvdSB0aGUgbGljZW5jZSB0byBqdXN0IHVzZQo+ID4g amEgZXZlbiBpZiBqYS1MYXRuIHdvdWxkIGJlIG1vcmUgcHJlY2lzZS4KPgo+IExlZ2FjeSBhcHBs aWNhdGlvbnMgYW5kIGNvbnRlbnQgZG9uJ3QgbmVlZCBhIGxpY2VuY2UsIHRoZXkKPiBjb3VsZG4n dCB1c2UgamEtTGF0biBiZWZvcmUgaXQgd2FzIHNwZWNpZmllZC4gIEFuZCB0aGV5J2xsCj4gY29u dGludWUgdG8gdXNlIGphIHVudGlsIHRoZXkgYXJlIHVwZ3JhZGVkIHRvIDQ2NDYgb3IgaXRzCj4g c3VjY2Vzc29yKHMpLCB0aGF0IGNvdWxkIHRha2UgZGVjYWRlcyAocGx1cmFsKS4KPgo+IEFsbCBu ZXcgYXBwbGljYXRpb25zIGJldHRlciB1c2UgYSB0YWcgamEtTGF0biB3aGVyZSB0aGF0J3MKPiBy ZWxldmFudC4gIEFuZCB0aGUgc2FtZSBuZXcgYXBwbGljYXRpb25zIG5lZWQgYSBsaWNlbmNlIHRv Cj4gc3VwcHJlc3MgSnBhbiBpbiBqYS1KcGFuIGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSwg dGhleQo+IG5lZWQgeW91ciBwcm9wb3NlZCBTdXBwcmVzcy1TY3JpcHQuCj4KPiBGcmFuawo+Cj4K Pgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gTHRy dSBtYWlsaW5nIGxpc3QKPiBMdHJ1QGlldGYub3JnCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbHRydQo+Cg== ------=_Part_341_12659825.1159493093633 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline WW91J3JlIHJlYWRpbmcgaW50byB0aGUgc3BlYyBydWxlcyB0aGF0IGRvbid0IGV4aXN0OyBTdXBw cmVzcy1TY3JpcHQgaXMgYSBTSE9VTEQgbm90IGEgTVVTVC4gSXQgaXMgcGVyZmVjdGx5IHZhbGlk IC0tIGFuZCByZWFzb25hYmxlIC0tIGZvciBtZSB0byB0YWcgYXMgZm9sbG93czo8YnI+PGJyPkEu IDxpPjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBpdGFsaWM7Ij4mbHQ7YmxhaCB4bWw6bGFuZz0n amEnJmd0Owo8L3NwYW4+a2Fuamk8L2k+ICg8YSBocmVmPSJodHRwOi8vZW4ud2lrdGlvbmFyeS5v cmcvd2lraS8lRTYlQkMlQTIlRTUlQUQlOTciIGNsYXNzPSJleHRpdyIgdGl0bGU9Indpa3Q65ryi 5a2XIj7mvKLlrZc8L2E+KSZsdDsvYmxhaCZndDs8YnI+PGJyPkkgZG9uJ3QgKmhhdmUqIHRvIGlu ZGljYXRlIHRoZSBzY3JpcHQuIE5vdywgSSBjb3VsZCBhbHNvIGNvcnJlY3RseSB0YWcgYXM6PGJy Pjxicj4KPGk+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IGl0YWxpYzsiPjxzcGFuIHN0eWxlPSJm b250LXN0eWxlOiBpdGFsaWM7Ij5CLiA8L3NwYW4+Jmx0O2JsYWggeG1sOmxhbmc9J2phLUxhdG4n Jmd0Ozwvc3Bhbj5rYW5qaTwvaT4mbHQ7L2JsYWgmZ3Q7Jmx0O2JsYWggPGk+PHNwYW4gc3R5bGU9 ImZvbnQtc3R5bGU6IGl0YWxpYzsiPnhtbDpsYW5nPSdqYS1KYXBuJzwvc3Bhbj48L2k+Jmd0OyAo CjxhIGhyZWY9Imh0dHA6Ly9lbi53aWt0aW9uYXJ5Lm9yZy93aWtpLyVFNiVCQyVBMiVFNSVBRCU5 NyIgY2xhc3M9ImV4dGl3IiB0aXRsZT0id2lrdDrmvKLlrZciPua8ouWtlzwvYT4pJmx0Oy9ibGFo Jmd0Ozxicj48aT48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogaXRhbGljOyI+PHNwYW4gc3R5bGU9 ImZvbnQtc3R5bGU6IGl0YWxpYzsiPkMuIDwvc3Bhbj4mbHQ7YmxhaCB4bWw6bGFuZz0namEnJmd0 Ozwvc3Bhbj4Ka2Fuamk8L2k+Jmx0Oy9ibGFoJmd0OyZsdDtibGFoIDxpPjxzcGFuIHN0eWxlPSJm b250LXN0eWxlOiBpdGFsaWM7Ij54bWw6bGFuZz0namEtSmFwbic8L3NwYW4+PC9pPiZndDsgKDxh IGhyZWY9Imh0dHA6Ly9lbi53aWt0aW9uYXJ5Lm9yZy93aWtpLyVFNiVCQyVBMiVFNSVBRCU5NyIg Y2xhc3M9ImV4dGl3IiB0aXRsZT0id2lrdDrmvKLlrZciPua8ouWtlzwvYT4pJmx0Oy9ibGFoJmd0 Ozxicj48aT48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogaXRhbGljOyI+CjxzcGFuIHN0eWxlPSJm b250LXN0eWxlOiBpdGFsaWM7Ij5ELiA8L3NwYW4+Jmx0O2JsYWggeG1sOmxhbmc9J2phLUxhdG4n Jmd0Ozwvc3Bhbj5rYW5qaTwvaT4mbHQ7L2JsYWgmZ3Q7Jmx0O2JsYWggPGk+PHNwYW4gc3R5bGU9 ImZvbnQtc3R5bGU6IGl0YWxpYzsiPnhtbDpsYW5nPSdqYSc8L3NwYW4+PC9pPiZndDsgKDxhIGhy ZWY9Imh0dHA6Ly9lbi53aWt0aW9uYXJ5Lm9yZy93aWtpLyVFNiVCQyVBMiVFNSVBRCU5NyIgY2xh c3M9ImV4dGl3IiB0aXRsZT0id2lrdDrmvKLlrZciPgrmvKLlrZc8L2E+KSZsdDsvYmxhaCZndDs8 YnI+PGJyPkFuZCBvZiBjb3Vyc2UsIEkgY291bGQgaW5jb3JyZWN0bHkgdGFnIGFzIHRoZSBmb2xs b3dpbmcsIG9yIG90aGVyIGludmFsaWQgdmFyaWFudHM6PGJyPjxpPjxzcGFuIHN0eWxlPSJmb250 LXN0eWxlOiBpdGFsaWM7Ij48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogaXRhbGljOyI+RS4gPC9z cGFuPiZsdDtibGFoIHhtbDpsYW5nPSdqYS1KYXBuJyZndDsKPC9zcGFuPmthbmppPC9pPiAoPGEg aHJlZj0iaHR0cDovL2VuLndpa3Rpb25hcnkub3JnL3dpa2kvJUU2JUJDJUEyJUU1JUFEJTk3IiBj bGFzcz0iZXh0aXciIHRpdGxlPSJ3aWt0Oua8ouWtlyI+5ryi5a2XPC9hPikmbHQ7L2JsYWgmZ3Q7 PGJyPkYuIDxpPjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBpdGFsaWM7Ij4mbHQ7YmxhaCB4bWw6 bGFuZz0namEtTGF0bicmZ3Q7PC9zcGFuPmthbmppPC9pPiAoPGEgaHJlZj0iaHR0cDovL2VuLndp a3Rpb25hcnkub3JnL3dpa2kvJUU2JUJDJUEyJUU1JUFEJTk3IiBjbGFzcz0iZXh0aXciIHRpdGxl PSJ3aWt0Oua8ouWtlyI+Cua8ouWtlzwvYT4pJmx0Oy9ibGFoJmd0Ozxicj48YnI+V2hhdCBNYXJ0 aW4gd2FzIHBvaW50aW5nIG91dCBpcyB0aGF0IGluIHNpdHVhdGlvbnMgbGlrZSB0aGlzLCBJIGNh biBleHRlcm5hbGx5IHZlcmlmeSBwcm9ncmFtbWF0aWNhbGx5IHRoYXQgRSBhbmQgRiBhcmUgaW5j b3JyZWN0OyBsaWJyYXJpZXMgdGhhdCB1c2UgdGhlIFVuaWNvZGUgQ2hhcmFjdGVyIERhdGFiYXNl IChsaWtlIElDVSBhbmQgb3RoZXJzKSBjYW4gZGV0ZXJtaW5lIHRoYXQgdGhlcmUgYXJlIGNoYXJh Y3RlcnMgaW4gdGhlIHNwYW4gdGhhdCBhcmUgbm90IEphcG4gYW5kIHRoZXJlIGFyZSBjaGFyYWN0 ZXJzIGluIEYgdGhhdCBhcmUgbm90IExhdG4uIEluIHN1Y2ggY2lyY3Vtc3RhbmNlcywgSSBkb24n dCBuZWVkIHRvIHN1cHBseSB0aGUgc2NyaXB0LiBbU2NyaXB0IHZhcmlhbnRzIGFyZSBhIGRpZmZl cmVudCBtYXR0ZXI7IEhhbnQgYW5kIEhhbnMgb3ZlcmxhcDogc29tZSBjaGFyYWN0ZXJzIGFyZSBj bGVhcmx5IG9ubHkgSGFudCBhbmQgc29tZSBjbGVhcmx5IG9ubHkgSGFucywgYnV0IG1hbnkgYXJl IHNoYXJlZC4gKFRoZXJlIGFyZSBvdGhlciBpc3N1ZXMgd2l0aCB0aGVzZSB0aGF0IEkgd29uJ3Qg Z28gaW50bykuXQo8YnI+PGJyPk1vcmVvdmVyLCB3aGVuIEkgc2FpZCAqaW5jb3JyZWN0KiwgaXQg aXMgbm90LCBvZiBjb3Vyc2UsIGEgY29uZm9ybWFuY2UgaXNzdWUuIFRoZXJlIGlzIG5vdGhpbmcg aW4gUkZDIDQ2NDYgdGhhdCByZXF1aXJlcyB0aGF0IGFueSBwYXJ0aWN1bGFyIHRleHQgYmUgY29y cmVjdGx5IHRhZ2dlZC4gVGhlIG9ubHkgdGhpbmcgdGhlIFJGQyBjYW4gZG8gZGV0ZXJtaW5lIHRo ZSBtZWFuaW5nIG9mICdqYS1KYXBuJywgbm90IGl0cyBjb3JyZWN0IGFwcGxpY2F0aW9uLgo8YnI+ PGJyPk1hcms8YnI+PGJyPjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiA5LzI4LzA2 LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+RnJhbmsgRWxsZXJtYW5uPC9iPiAmbHQ7PGEg aHJlZj0ibWFpbHRvOm5vYm9keUB4eXp6eS5jbGFyYW5ldC5kZSI+bm9ib2R5QHh5enp5LmNsYXJh bmV0LmRlPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJn aW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgpNYXJ0aW4gRHVlcnN0 IHdyb3RlOjxicj48YnI+Jmd0OyBhbiBpbnRlcmVzdGluZyBhc3BlY3Qgb2YgbGFuZ3VhZ2UgdGFn Z2luZyB0aGF0IG1heWJlIHdlPGJyPiZndDsgc2hvdWxkIG1lbnRpb24gaW4gdGhlIFJGQyA0NjQ2 YmlzOiBUaGUgc2NyaXB0IGNhbiBiZSBsZWZ0PGJyPiZndDsgb3V0IGlmIGl0J3Mgb2J2aW91cyBm cm9tIHRoZSBkYXRhLjxicj48YnI+SSBkb24ndCBnZXQgdGhpcywgJnF1b3Q7bGFuZ3VhZ2UgdGFn Z2luZyBpcyB1bm5lY2Vzc2FyeSBpZiB0aGUKPGJyPmxhbmd1YWdlIGlzIG9idmlvdXMgZnJvbSB0 aGUgZGF0YSZxdW90OyB3b3VsZCBiZSBhIHZlcnkgc2ltaWxhcjxicj5zdGF0ZW1lbnQuJm5ic3A7 Jm5ic3A7V2hhdCdzICZxdW90O29idmlvdXMmcXVvdDsgYWJvdXQgYSBzY3JpcHQgaW4gdGhlIGFn ZSBvZjxicj5Vbmljb2RlID8mbmJzcDsmbmJzcDtPZiBjb3Vyc2UgdGhlIHNjcmlwdCBzaG91bGQg YmUgbGVmdCBvdXQgaWYgaXQnczxicj5pcnJlbGV2YW50IChzcG9rZW4gY29udGVudCksIGJ1dCB0 aGF0J3MgYW5vdGhlciBjYXNlLgo8YnI+PGJyPiZndDsgVGhpcyBpbiBteSB2aWV3IGRvZXNuJ3Qg anVzdGlmeSB0byBub3QgdXNlIEpwYW4gYXMgYTxicj4mZ3Q7IHN1cHJlc3Mtc2NyaXB0LCBidXQg aXQgZ2l2ZXMgeW91IHRoZSBsaWNlbmNlIHRvIGp1c3QgdXNlPGJyPiZndDsgamEgZXZlbiBpZiBq YS1MYXRuIHdvdWxkIGJlIG1vcmUgcHJlY2lzZS48YnI+PGJyPkxlZ2FjeSBhcHBsaWNhdGlvbnMg YW5kIGNvbnRlbnQgZG9uJ3QgbmVlZCBhIGxpY2VuY2UsIHRoZXkKPGJyPmNvdWxkbid0IHVzZSBq YS1MYXRuIGJlZm9yZSBpdCB3YXMgc3BlY2lmaWVkLiZuYnNwOyZuYnNwO0FuZCB0aGV5J2xsPGJy PmNvbnRpbnVlIHRvIHVzZSBqYSB1bnRpbCB0aGV5IGFyZSB1cGdyYWRlZCB0byA0NjQ2IG9yIGl0 czxicj5zdWNjZXNzb3IocyksIHRoYXQgY291bGQgdGFrZSBkZWNhZGVzIChwbHVyYWwpLjxicj48 YnI+QWxsIG5ldyBhcHBsaWNhdGlvbnMgYmV0dGVyIHVzZSBhIHRhZyBqYS1MYXRuIHdoZXJlIHRo YXQncwo8YnI+cmVsZXZhbnQuJm5ic3A7Jm5ic3A7QW5kIHRoZSBzYW1lIG5ldyBhcHBsaWNhdGlv bnMgbmVlZCBhIGxpY2VuY2UgdG88YnI+c3VwcHJlc3MgSnBhbiBpbiBqYS1KcGFuIGZvciBiYWNr d2FyZHMgY29tcGF0aWJpbGl0eSwgdGhleTxicj5uZWVkIHlvdXIgcHJvcG9zZWQgU3VwcHJlc3Mt U2NyaXB0Ljxicj48YnI+RnJhbms8YnI+PGJyPjxicj48YnI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPGJyPkx0cnUgbWFpbGluZyBsaXN0PGJyPjxhIGhy ZWY9Im1haWx0bzpMdHJ1QGlldGYub3JnIj5MdHJ1QGlldGYub3JnPC9hPjxicj48YSBocmVmPSJo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1Ij5odHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1PC9hPjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+ PGJyPgo= ------=_Part_341_12659825.1159493093633-- --===============1677978725== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1677978725==-- From ltru-bounces@ietf.org Thu Sep 28 21:32:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT7ER-0005e6-Qb; Thu, 28 Sep 2006 21:32:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT7EQ-0005df-J2 for ltru@lists.ietf.org; Thu, 28 Sep 2006 21:32:02 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT7EP-0007pU-8r for ltru@lists.ietf.org; Thu, 28 Sep 2006 21:32:02 -0400 Received: by nf-out-0910.google.com with SMTP id n15so929123nfc for ; Thu, 28 Sep 2006 18:32:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=MKoTewLstWndZmiJXaZrzB/J35iz98X1r20vnw5iNyHrFa8DWVTzFcrfoz7rMDLKeYRSX1yFZnxvmr/YWMvPVQgfN/U6en+ocRu5Xlx2GmFM7mdX7k7QUX6o+rVyhuR7CKNg6TSbeA5Hto3zp0ya4juYEK7i8snE+3kWdA/cwt8= Received: by 10.49.8.15 with SMTP id l15mr840479nfi; Thu, 28 Sep 2006 18:32:00 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Thu, 28 Sep 2006 18:32:00 -0700 (PDT) Message-ID: <30b660a20609281832v736421f0q9ae0e1384a00316a@mail.gmail.com> Date: Thu, 28 Sep 2006 18:32:00 -0700 From: "Mark Davis" To: ltru@lists.ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: 0ad84008d194a02c X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [Ltru] Small fix to text on Suppress Script X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0657978493==" Errors-To: ltru-bounces@ietf.org --===============0657978493== Content-Type: multipart/alternative; boundary="----=_Part_409_6177834.1159493520093" ------=_Part_409_6177834.1159493520093 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Frank's message brought up an issue -- the following text should be changed in Addison's copy. This field indicates a script used to write the overwhelming majority of documents for the given language and that therefore adds no distinguishing information to a language tag. It no => little helps ensure greater compatibility between the language tags generated according to the rules in this document and language tags and tag processors or consumers based on RFC 3066. For example, virtually all Icelandic documents are written in the Latin script, making the subtag 'Latn' redundant in the tag "is-Latn". => making the subtag 'Latn' in "is-Latn" redundant in all typical cases. The text further down is ok, since it is correctly qualified to "most applications". The field 'Suppress-Script' in the primary language record in the registry indicates which script subtags do not add distinguishing information for most applications. ------=_Part_409_6177834.1159493520093 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Frank's message brought up an issue -- the following text should be changed in Addison's copy.

This field indicates a script used to write the
   overwhelming majority of documents for the given language and that

   therefore adds no distinguishing information to a language tag.  It
no => little
   helps ensure greater compatibility between the language tags
   generated according to the rules in this document and language tags

   and tag processors or consumers based on RFC 3066.  For example,
   virtually all Icelandic documents are written in the Latin script,
   making the subtag 'Latn' redundant in the tag "is-Latn".

=> making the subtag 'Latn' in "is-Latn" redundant in all typical cases.

The text further down is ok, since it is correctly qualified to "most applications".


       The
       field 'Suppress-Script' in the primary language record in the
       registry indicates which script subtags do not add distinguishing
       information for most applications. 
------=_Part_409_6177834.1159493520093-- --===============0657978493== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0657978493==-- From ltru-bounces@ietf.org Thu Sep 28 22:50:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT8SS-0002x4-5j; Thu, 28 Sep 2006 22:50:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT8SR-0002wz-42 for ltru@lists.ietf.org; Thu, 28 Sep 2006 22:50:35 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT8SM-0003z7-Qj for ltru@lists.ietf.org; Thu, 28 Sep 2006 22:50:35 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GT8S7-0002lJ-FV for ltru@lists.ietf.org; Fri, 29 Sep 2006 04:50:16 +0200 Received: from du-017-248.access.de.clara.net ([212.82.246.248]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Sep 2006 04:50:15 +0200 Received: from nobody by du-017-248.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Sep 2006 04:50:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 29 Sep 2006 04:49:00 +0200 Organization: Lines: 13 Message-ID: <451C899C.3C0E@xyzzy.claranet.de> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> <6.0.0.20.2.20060928193237.08122670__32691.3689300001$1159440247$gmane$org@localhost> <451C66A3.52C9@xyzzy.claranet.de> <30b660a20609281824m560066c0k1202af61d673e724@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-017-248.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] Re: Korean (and Japanese) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > You're reading into the spec rules that don't exist; > Suppress-Script is a SHOULD not a MUST. [...] >> All new applications better use a tag ja-Latn where >> that's relevant. ------------------------^^^^^^^^^^ This "better use" reflects the meaning of a SHOULD, or are you talking about something else ? See also :-) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 28 23:44:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT9Ii-0002Hw-EN; Thu, 28 Sep 2006 23:44:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT9Ig-0002Hr-MT for ltru@lists.ietf.org; Thu, 28 Sep 2006 23:44:34 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT9Ie-0002TK-Fz for ltru@lists.ietf.org; Thu, 28 Sep 2006 23:44:34 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GT9Ie-00031m-3x; Thu, 28 Sep 2006 23:44:32 -0400 Date: Thu, 28 Sep 2006 23:44:32 -0400 To: Mark Davis Subject: Re: [Ltru] Re: Korean (and Japanese) Message-ID: <20060929034431.GH3780@ccil.org> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> <6.0.0.20.2.20060928193237.08122670__32691.3689300001$1159440247$gmane$org@localhost> <451C66A3.52C9@xyzzy.claranet.de> <30b660a20609281824m560066c0k1202af61d673e724@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20609281824m560066c0k1202af61d673e724@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > What Martin was pointing out is that in situations like this, I can > externally verify programmatically that E and F are incorrect; libraries > that use the Unicode Character Database (like ICU and others) can > determine that there are characters in the span that are not Japn and > there are characters in F that are not Latn. Well, only probabilistically. An English text is still in Latn even if (like the one I'm reading now) it contains the occasional Greek word in the Greek script. For that matter, it's still in English even though there are occasional quotations in German. -- What is the sound of Perl? Is it not the John Cowan sound of a [Ww]all that people have stopped cowan@ccil.org banging their head against? --Larry http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 01:45:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTBBj-0006wF-I8; Fri, 29 Sep 2006 01:45:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSy5l-0003ms-3C for ltru@ietf.org; Thu, 28 Sep 2006 11:46:29 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSy3u-00058A-5O for ltru@ietf.org; Thu, 28 Sep 2006 11:44:38 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8SFiRKa015177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Sep 2006 08:44:27 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8SFiPsk015691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Sep 2006 08:44:26 -0700 Date: Thu, 28 Sep 2006 08:44:25 -0700 (PDT) From: Mark Crispin To: Martin Duerst In-Reply-To: <6.0.0.20.2.20060928193237.08122670@localhost> Message-ID: References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> <6.0.0.20.2.20060928193237.08122670@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-2022-JP; format=flowed X-PMX-Version: 5.2.0.266434, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.9.28.80942 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='LOCALE_JAPANESE 0, __CHAR_JAPANESE_CT 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_CHARSET_FARAWAY 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Fri, 29 Sep 2006 01:45:29 -0400 Cc: ietf-languages@iana.org, LTRU Working Group , Masayasu Ishikawa Subject: [Ltru] Re: Korean (and Japanese) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Thu, 28 Sep 2006, Martin Duerst wrote: > On that level, the main usages of the information > are e.g. for text-to-speach. What you want is that your name > is pronounced in the Japanese way rather than the way an > English (or some other language) speaker would pronounce it. > The characters are there in the data, so tagging the script > would actually be overkill, either redundant or contradictory. Interesting point. So I assume that means that "karaoke" tagged as ja-Latn would be pronounced (somewhat like "kah-rah-oh-kay" to an English speaker), whereas "karaoke" tagged as "en" would be pronounced as "kerry-oh-key"? :-) -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 01:48:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTBEr-0007xY-P2; Fri, 29 Sep 2006 01:48:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTBEq-0007xT-MQ for ltru@ietf.org; Fri, 29 Sep 2006 01:48:44 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTBEp-0001yB-DH for ltru@ietf.org; Fri, 29 Sep 2006 01:48:44 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060929054842.QKEJ8494.mta9.adelphia.net@DGBP7M81> for ; Fri, 29 Sep 2006 01:48:42 -0400 Message-ID: <005701c6e38a$ec172690$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 28 Sep 2006 22:48:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] Re: OT: ISO/IEC 10646 and ISO/IEC 14651 freely available X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> fr-1 to mean "french spoken by a man" or zh-2 (chinese as spoken by a >> woman). > > That could get extension "s", extension "l" is for locations, > en-scouse-l-airport = "Scouse as spoken on airports". Joke off, no > issue, 4646 requires "IETF consensus" for extensions. ftp://ftp.rfc-editor.org/in-notes/rfc4589.txt Location types could easily be divided into 8-character blocks, to fit the syntax. It is strange that this hasn't already been... ah, never mind. -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 03:32:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTCr8-0003Qp-GN; Fri, 29 Sep 2006 03:32:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTCr6-0003PQ-TY for ltru@ietf.org; Fri, 29 Sep 2006 03:32:20 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTCr5-0003Ba-1m for ltru@ietf.org; Fri, 29 Sep 2006 03:32:20 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060929073217.RSDF8494.mta9.adelphia.net@DGBP7M81> for ; Fri, 29 Sep 2006 03:32:17 -0400 Message-ID: <00f901c6e399$643dc8f0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Fri, 29 Sep 2006 00:32:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: c96e11e58076fc8e92061fb6cbdfae15 Subject: [Ltru] Submission: draft-ietf-ltru-4645bis-00 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I've submitted the text version of draft-ietf-ltru-4645bis-00 to Internet-Drafts. It's been checked with idnits and weighs in at over 800,000 bytes and 884 pages. Below is the text, with the Registry contents snipped (as they will be before the draft becomes an RFC). Full, uncut versions of this file are available at: http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-00.txt http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-00.html http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-00.xml Please note there are no links from my home page to these documents. I'll add them when I get time. Do NOT attempt to print these documents unless you own stock in a paper mill. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 -----8<-----cut here-----8<-----cut here-----8<-----cut here-----8<----- LTRU D. Ewell, Ed. Internet-Draft Consultant Intended status: Informational September 28, 2006 Expires: April 1, 2007 Update to the Language Subtag Registry draft-ietf-ltru-4645bis-00 Status of this Memo 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 becomes aware will be disclosed, in accordance with 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 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 April 1, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Ewell Expires April 1, 2007 [Page 1] Internet-Draft Update to the Language Subtag Registry September 2006 Abstract This memo defines the procedure used to update the IANA Language Subtag Registry in conjunction with the publication of RFC 4646bis [RFC EDITOR NOTE: replace with actual RFC number], 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Updating the Registry . . . . . . . . . . . . . . . . . . . . 4 2.1. Starting Point . . . . . . . . . . . . . . . . . . . . . 4 2.2. New Subtags . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Modified Subtags . . . . . . . . . . . . . . . . . . . . 5 2.4. Grandfathered and Redundant Tags . . . . . . . . . . . . 6 3. Updated Registry Contents . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 879 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 880 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 881 6.1. Normative References . . . . . . . . . . . . . . . . . . 881 6.2. Informative References . . . . . . . . . . . . . . . . . 881 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 883 Intellectual Property and Copyright Statements . . . . . . . . . 884 Ewell Expires April 1, 2007 [Page 2] Internet-Draft Update to the Language Subtag Registry September 2006 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 phase, 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. Ewell Expires April 1, 2007 [Page 3] Internet-Draft Update to the Language Subtag Registry September 2006 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.] o [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). o [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: Ewell Expires April 1, 2007 [Page 4] Internet-Draft Update to the Language Subtag Registry September 2006 o 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. o 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.) o 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: o If the name listed in [ISO639-3] included the substring "(generic)", the substring and preceding space were deleted. o 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 Ewell Expires April 1, 2007 [Page 5] Internet-Draft Update to the Language Subtag Registry September 2006 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 Section 2.1 of [draft-4646bis]. 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: Ewell Expires April 1, 2007 [Page 6] Internet-Draft Update to the Language Subtag Registry September 2006 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) Ewell Expires April 1, 2007 [Page 7] Internet-Draft Update to the Language Subtag Registry September 2006 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. Ewell Expires April 1, 2007 [Page 8] Internet-Draft Update to the Language Subtag Registry September 2006 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 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. << Registry contents deleted >> Ewell Expires April 1, 2007 [Page 878] Internet-Draft Update to the Language Subtag Registry September 2006 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]. Ewell Expires April 1, 2007 [Page 879] Internet-Draft Update to the Language Subtag Registry September 2006 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 under "Language Tags". For details on the procedures for the format and ongoing maintenance of this Registry, see [draft-4646bis]. Ewell Expires April 1, 2007 [Page 880] Internet-Draft Update to the Language Subtag Registry September 2006 6. References 6.1. Normative References [ISO639-3] International Organization for Standardization, "ISO/FDIS 639-3:2006. Codes for the representation of names of languages -- Part 3: Alpha-3 code for comprehensive coverage of languages, first edition", 2006. [draft-4646bis] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", September 2006. [iso-dis-639-3-macrolanguages_20060922] International Organization for Standardization, "ISO/DIS 639-3 macrolanguage mappings", September 2006, . [iso-dis-639-3_20060421] International Organization for Standardization, "ISO/DIS 639-3 code set", April 2006, . 6.2. Informative References [ISO15924] International Organization for Standardization, "ISO 15924:2004. Information and documentation -- Codes for the representation of names of scripts", January 2004. [ISO3166-1] International Organization for Standardization, "ISO 3166: 1988. Codes for the representation of names of countries, 3rd edition", August 1988. [ISO639-1] International Organization for Standardization, "ISO 639- 1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code", 2002. [ISO639-2] International Organization for Standardization, "ISO 639- 2:1998. Codes for the representation of names of languages -- Part 2: Alpha-3 code, first edition", 1998. [RFC1766] Alvestrand, H., "Tags for the Identification of Ewell Expires April 1, 2007 [Page 881] Internet-Draft Update to the Language Subtag Registry September 2006 Languages", RFC 1766, March 1995. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", RFC 3066, January 2001. [RFC4645] Ewell, D., "Initial Language Subtag Registry", RFC 4645, September 2006. [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006. [UN_M.49] Statistics 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. Ewell Expires April 1, 2007 [Page 882] Internet-Draft Update to the Language Subtag Registry September 2006 Author's Address Doug Ewell (editor) Consultant Email: dewell@adelphia.net URI: http://users.adelphia.net/~dewell Ewell Expires April 1, 2007 [Page 883] Internet-Draft Update to the Language Subtag Registry September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Ewell Expires April 1, 2007 [Page 884] _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 03:52:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTDAw-0006hs-JV; Fri, 29 Sep 2006 03:52:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTDAu-0006dg-BM for ltru@lists.ietf.org; Fri, 29 Sep 2006 03:52:48 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTCyN-0004L5-Az for ltru@lists.ietf.org; Fri, 29 Sep 2006 03:39:52 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id AF2E026C134; Fri, 29 Sep 2006 09:39:21 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 8F05B26C0E8; Fri, 29 Sep 2006 09:39:20 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 8270958EBBD; Fri, 29 Sep 2006 09:39:20 +0200 (CEST) Date: Fri, 29 Sep 2006 09:39:20 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20060929073920.GA28926@nic.fr> References: <451B4901.3D41@xyzzy.claranet.de> <20060928120636.GA14607@sources.org> <451C5EB9.725F@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <451C5EB9.725F@xyzzy.claranet.de> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: OT: ISO/IEC 10646 and ISO/IEC 14651 freely available X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [Still off-topic but interesting] On Fri, Sep 29, 2006 at 01:46:01AM +0200, Frank Ellermann wrote a message of 9 lines which said: > That could get extension "s", extension "l" is for locations, > en-scouse-l-airport = "Scouse as spoken on airports". It seems that, for some languages and cultures, there *is* a difference between the language spoken by the men and the one spoken by the women (see http://www.ethnologue.com/show_subject.asp?code=WSP). I'm not aware of differences in speech depending on the location. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 05:05:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTEIp-0004pB-IK; Fri, 29 Sep 2006 05:05:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTEIo-0004p6-LF for ltru@ietf.org; Fri, 29 Sep 2006 05:05:02 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTEIl-0000Rt-Pc for ltru@ietf.org; Fri, 29 Sep 2006 05:05:02 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8T94uTO008927 for ; Fri, 29 Sep 2006 18:04:56 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 6a1e_939e2326_4f99_11db_8345_0014221fa3c9; Fri, 29 Sep 2006 18:04:55 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:37578) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 29 Sep 2006 18:04:51 +0900 Message-Id: <6.0.0.20.2.20060929175121.09943600@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 29 Sep 2006 18:04:36 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Submission: draft-ietf-ltru-4645bis-00 In-Reply-To: <00f901c6e399$643dc8f0$6401a8c0@DGBP7M81> References: <00f901c6e399$643dc8f0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Doug, Congratulations and thanks for this huge work! At 16:32 06/09/29, Doug Ewell wrote: >I've submitted the text version of draft-ietf-ltru-4645bis-00 to Internet-Drafts. It's been checked with idnits and weighs in at over 800,000 bytes and 884 pages. > >Below is the text, with the Registry contents snipped (as they will be before the draft becomes an RFC). Full, uncut versions of this file are available at: > >http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-00.txt >http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-00.html >http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-00.xml > >Please note there are no links from my home page to these documents. I'll add them when I get time. > >Do NOT attempt to print these documents unless you own stock in a paper mill. Well, it's actually not that bad. I usually print Internet-Drafts 2-up both sides, and then there is also a little bonus in this part of the world because the pages are designed for letter format, but A4 is a bit higher. Overall about 200 pages, which costs about 2$ or so (not that I have done it yet). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 05:56:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTF69-00060D-Re; Fri, 29 Sep 2006 05:56:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTF68-000608-Hx for ltru@ietf.org; Fri, 29 Sep 2006 05:56:00 -0400 Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTF67-0007Ib-64 for ltru@ietf.org; Fri, 29 Sep 2006 05:56:00 -0400 Received: from eupig2 (unverified [129.1.30.40]) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Fri, 29 Sep 2006 09:55:54 +0000 Received: from LONSMSXB02.emea.ime.reuters.com ([10.14.113.7]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31217) with ESMTP id <0J6C008K2M96NS@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Fri, 29 Sep 2006 09:55:54 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by LONSMSXB02.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Fri, 29 Sep 2006 10:55:53 +0100 Date: Fri, 29 Sep 2006 10:54:57 +0100 From: Misha Wolf To: ltru@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: Re-use of a region code for the same purpose [was: Re: ISO 3166-1 newsletter on Serbia and Montenegro] Thread-Index: Acbh99sYekIZlBTSTE+xkKLx/BWWFgBtOKSQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 29 Sep 2006 09:55:54.0151 (UTC) FILETIME=[73FDFB70:01C6E3AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Ltru] Re-use of a region code for the same purpose [was: Re: ISO 3166-1 newsletter on Serbia and Montenegro] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [Moving to LTRU] Hi Doug or anyone else, Please could you explain the reasoning for this. Thanks, Misha -----Original Message----- From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of Doug Ewell Sent: 27 September 2006 06:43 To: ietf-languages@iana.org Subject: Re: ISO 3166-1 newsletter on Serbia and Montenegro [...] We can only deprecate CS this one time. If ISO 3166/MA=20 re-reused it, for a reunified Serbia and Montenegro [...],=20 we would have to press a UN M.49 3-digit code element into=20 service as a region subtag. We did that on purpose. [...] This email was sent to you by Reuters, the global news and information comp= any.=20 To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 09:28:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTIPm-000812-Ea; Fri, 29 Sep 2006 09:28:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTIPl-00080K-Pj for ltru@ietf.org; Fri, 29 Sep 2006 09:28:29 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTIPk-0004mn-Id for ltru@ietf.org; Fri, 29 Sep 2006 09:28:29 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GTIPk-0007Mk-5U; Fri, 29 Sep 2006 09:28:28 -0400 Date: Fri, 29 Sep 2006 09:28:28 -0400 To: Misha Wolf Subject: Re: [Ltru] Re-use of a region code for the same purpose [was: Re: ISO 3166-1 newsletter on Serbia and Montenegro] Message-ID: <20060929132828.GJ3780@ccil.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Misha Wolf scripsit: > Doug Ewell wrote: > > We can only deprecate CS this one time. If ISO 3166/MA > > re-reused it, for a reunified Serbia and Montenegro [...], > > we would have to press a UN M.49 3-digit code element into > > service as a region subtag. We did that on purpose. > > Please could you explain the reasoning for this. Sure. In general, we object very strongly to reused codes; if "en" means "English" now, it shouldn't mean "French" at some time in the future. For languages and scripts, the ISO Registration Authorities guarantee that level of stability. Country codes are a different story. There are only 676 possible, about 10% are taken up by things that are not countries (like EU for the European Union), and the Maintenance Agency issues a new code when a country's name changes substantially. They have reused codes in the past, and they will have to in the future, although they have promised henceforth not to reuse a code for at least 50 years after its abandonment. Fortunately, each country is assigned a 3-digit number by the U.N., so if and when a country code *is* reused, we will ignore that and register the 3-digit number for it instead. We don't apply this rule when the code was abandoned before RFC 1766 was published. CS is a particularly notorious case: it was assigned to Czechoslovakia and then abandoned when that country broke up, and then was assigned again (before the 50-year rule) for Serbia & Montenegro and abandoned a second time when *that* country broke up. (We decided reluctantly to accept this *fait accompli* and register the latter assignment.) If it's assigned a third time, presumably only in the latter half of this century, the new assignment will be ignored, and the U.N. numeric code registered instead. (My remark "hopefully for the last time" was nothing but an ill-timed jest.) -- John Cowan cowan@ccil.org "You need a change: try Canada" "You need a change: try China" --fortune cookies opened by a couple that I know _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 09:34:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTIVa-0003NE-A1; Fri, 29 Sep 2006 09:34:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTIVZ-0003N9-IX for ltru@ietf.org; Fri, 29 Sep 2006 09:34:29 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTIVY-00068j-93 for ltru@ietf.org; Fri, 29 Sep 2006 09:34:29 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060929133427.SLAQ437.mta13.adelphia.net@DGBP7M81> for ; Fri, 29 Sep 2006 09:34:27 -0400 Message-ID: <012f01c6e3cb$fbd25690$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Fri, 29 Sep 2006 06:34:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ltru] Registry deltas X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Would it be useful to the group, for evaluation purposes, if I produced a diff file containing the changes between the existing Registry and the one proposed in draft-4645bis-00? This would exclude the 7,200 added subtags and include only the other changes, such as Descriptions and Comments added, grandfathered tags changed to redundant, and such. I know I've relied on such deltas while working on it. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 09:35:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTIWS-0003qZ-SY; Fri, 29 Sep 2006 09:35:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTIWS-0003oR-8y for ltru@ietf.org; Fri, 29 Sep 2006 09:35:24 -0400 Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime03.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTIWQ-0006Uv-TG for ltru@ietf.org; Fri, 29 Sep 2006 09:35:24 -0400 Received: from eupig2 (unverified [129.1.30.40]) by lonsmime03.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Fri, 29 Sep 2006 13:35:21 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31217) with ESMTP id <0J6C001L5WEXG9@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Fri, 29 Sep 2006 13:35:21 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Fri, 29 Sep 2006 14:35:21 +0100 Date: Fri, 29 Sep 2006 14:33:51 +0100 From: Misha Wolf Subject: RE: [Ltru] Re-use of a region code for the same purpose [was: Re: ISO 3166-1 newsletter on Serbia and Montenegro] To: ltru@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Re-use of a region code for the same purpose [was: Re: ISO 3166-1 newsletter on Serbia and Montenegro] Thread-Index: AcbjyydjA7sfVLu2SleTlNnzIIj22QAABEIQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 29 Sep 2006 13:35:21.0538 (UTC) FILETIME=[1C5DCA20:01C6E3CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > > Doug Ewell wrote: > > > We can only deprecate CS this one time. If ISO 3166/MA=20 > > > re-reused it, for a reunified Serbia and Montenegro [...],=20 > > > we would have to press a UN M.49 3-digit code element into=20 > > > service as a region subtag. We did that on purpose. > >=20 > > Please could you explain the reasoning for this. >=20 > Sure. In general, we object very strongly to reused codes;=20 Let's consider some case other than "CS". If Switzerland=20 split into two countries, and five years later the two=20 re-united, is there any reason why ISO and we should not=20 use the original "CH"? Misha This email was sent to you by Reuters, the global news and information comp= any.=20 To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 09:43:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTIdp-0007lP-1j; Fri, 29 Sep 2006 09:43:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTIdo-0007lK-0I for ltru@ietf.org; Fri, 29 Sep 2006 09:43:00 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTIdm-000089-Po for ltru@ietf.org; Fri, 29 Sep 2006 09:42:59 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GTIdm-0007jC-Ik; Fri, 29 Sep 2006 09:42:58 -0400 Date: Fri, 29 Sep 2006 09:42:58 -0400 To: Misha Wolf Subject: Re: [Ltru] Re-use of a region code for the same purpose [was: Re: ISO 3166-1 newsletter on Serbia and Montenegro] Message-ID: <20060929134258.GK3780@ccil.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Misha Wolf scripsit: > Let's consider some case other than "CS". If Switzerland > split into two countries, and five years later the two > re-united, is there any reason why ISO and we should not > use the original "CH"? All recent unifications have been, in fact and in law, the absorption of one country or de facto country by another. Thus the situation seems unlikely to occur in fact. If a unification re-created a former country exactly, we might bend our rules, I suppose. -- John Cowan cowan@ccil.org http://ccil.org/~cowan The present impossibility of giving a scientific explanation is no proof that there is no scientific explanation. The unexplained is not to be identified with the unexplainable, and the strange and extraordinary nature of a fact is not a justification for attributing it to powers above nature. --The Catholic Encyclopedia, s.v. "telepathy" (1913) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 09:48:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTIj5-0003EV-Jd; Fri, 29 Sep 2006 09:48:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTIj4-0003Bv-17 for ltru@lists.ietf.org; Fri, 29 Sep 2006 09:48:26 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTIj2-0000V3-Qr for ltru@lists.ietf.org; Fri, 29 Sep 2006 09:48:26 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GTIj1-0007se-QE; Fri, 29 Sep 2006 09:48:23 -0400 Date: Fri, 29 Sep 2006 09:48:23 -0400 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: OT: ISO/IEC 10646 and ISO/IEC 14651 freely available Message-ID: <20060929134823.GP3780@ccil.org> References: <451B4901.3D41@xyzzy.claranet.de> <20060928120636.GA14607@sources.org> <451C5EB9.725F@xyzzy.claranet.de> <20060929073920.GA28926@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060929073920.GA28926@nic.fr> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer scripsit: > I'm not aware of differences in speech depending on the location. People do talk differently at home, at the workplace, and in church, but I don't think the issue rises to the level of language tagging yet. If someone needed this information (as for tagging a multilingual speech corpus), either -x- or a registered extension would be appropriate. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Assent may be registered by a signature, a handshake, or a click of a computer mouse transmitted across the invisible ether of the Internet. Formality is not a requisite; any sign, symbol or action, or even willful inaction, as long as it is unequivocally referable to the promise, may create a contract. --Specht v. Netscape _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 10:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTJXi-0001QU-Ob; Fri, 29 Sep 2006 10:40:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTJXh-0001Q3-G7 for ltru@lists.ietf.org; Fri, 29 Sep 2006 10:40:45 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTJXg-0006Kk-4X for ltru@lists.ietf.org; Fri, 29 Sep 2006 10:40:45 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1067867nfc for ; Fri, 29 Sep 2006 07:40:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=cA+lcpFCHrKJTJ6bKJr6yyFhz7LfMLgnTuxh/Lh3zQzWsqOGXHDCb/hC0v6w5/a6AnF9Z5HRX35LJNDkPEMZDcVhiUzjuFTddTtBP1k2mvv1StsbjtvfCYDRkRjtC8BOaewRxInle+rNwkTnEp9dG0eH+NoPIcVmr9wbKC8A2co= Received: by 10.48.162.15 with SMTP id k15mr1615097nfe; Fri, 29 Sep 2006 07:40:42 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Fri, 29 Sep 2006 07:40:42 -0700 (PDT) Message-ID: <30b660a20609290740nc2c3f8bp7985c80202a7d7f@mail.gmail.com> Date: Fri, 29 Sep 2006 07:40:42 -0700 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: Korean (and Japanese) In-Reply-To: <451C899C.3C0E@xyzzy.claranet.de> MIME-Version: 1.0 References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> <6.0.0.20.2.20060928193237.08122670__32691.3689300001$1159440247$gmane$org@localhost> <451C66A3.52C9@xyzzy.claranet.de> <30b660a20609281824m560066c0k1202af61d673e724@mail.gmail.com> <451C899C.3C0E@xyzzy.claranet.de> X-Google-Sender-Auth: 34f458da56f15ecc X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1031418159==" Errors-To: ltru-bounces@ietf.org --===============1031418159== Content-Type: multipart/alternative; boundary="----=_Part_11038_10977063.1159540842486" ------=_Part_11038_10977063.1159540842486 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I wasn't talking about that. I was talking about your sentence: "And the same new applications need a licence to suppress Jpan in ja-Jpan for backwards compatibility, they need your proposed Suppress-Script." This is untrue. I need no licence to tag anything as simply 'ja' (instead of ja-), if that's all I want to tag it with. Mark On 9/28/06, Frank Ellermann wrote: > > Mark Davis wrote: > > > You're reading into the spec rules that don't exist; > > Suppress-Script is a SHOULD not a MUST. > [...] > >> All new applications better use a tag ja-Latn where > >> that's relevant. > ------------------------^^^^^^^^^^ > This "better use" reflects the meaning of a SHOULD, or > are you talking about something else ? > > See also :-) > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_11038_10977063.1159540842486 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I wasn't talking about that. I was talking about your sentence:

"And the same new applications need a licence to
suppress Jpan in ja-Jpan for backwards compatibility, they
need your proposed Suppress-Script."

This is untrue. I need no licence to tag anything as simply 'ja' (instead of ja-<somescript>), if that's all I want to tag it with.

Mark

On 9/28/06, Frank Ellermann <nobody@xyzzy.claranet.de> wrote:
Mark Davis wrote:

> You're reading into the spec rules that don't exist;
> Suppress-Script is a SHOULD not a MUST.
[...]
>> All new applications better use a tag ja-Latn where
>> that's relevant.
------------------------^^^^^^^^^^
This "better use" reflects the meaning of a SHOULD, or
are you talking about something else ?

See also <http://purl.net/xyzzy/kex/mustard.kex > :-)



_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

------=_Part_11038_10977063.1159540842486-- --===============1031418159== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1031418159==-- From ltru-bounces@ietf.org Fri Sep 29 10:50:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTJh6-000872-Op; Fri, 29 Sep 2006 10:50:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTJgh-0007JD-7B; Fri, 29 Sep 2006 10:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTJgg-00077a-NI; Fri, 29 Sep 2006 10:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id A93CF26E42; Fri, 29 Sep 2006 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GTJgg-0000bL-Ia; Fri, 29 Sep 2006 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 29 Sep 2006 10:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-4645bis-00.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Update to the Language Subtag Registry Author(s) : D. Ewell Filename : draft-ietf-ltru-4645bis-00.txt Pages : 884 Date : 2006-9-29 This memo defines the procedure used to update the IANA Language Subtag Registry in conjunction with the publication of RFC 4646bis [RFC EDITOR NOTE: replace with actual RFC number], 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-4645bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-4645bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-4645bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-9-29051515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-4645bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-4645bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-29051515.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@ietf.org Fri Sep 29 11:09:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTJzf-00045G-Nc; Fri, 29 Sep 2006 11:09:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTJze-00044j-0T for ltru@lists.ietf.org; Fri, 29 Sep 2006 11:09:38 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTJzc-0001zB-Hg for ltru@lists.ietf.org; Fri, 29 Sep 2006 11:09:37 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1075640nfc for ; Fri, 29 Sep 2006 08:09:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ihpCoDre+16H+TN2LlcJz950vykHmMSoJHFP7zipszwx/0LbtwNTcVbWCDlbG2NS8K0yZ2ZSypYK+puXlWomAf2KdkszazV7i3fZ/EQ3LR5A+baAUTfaer9hgzF3crtN71Ms5/+GVq6KDeMInYQJJEuoosLkGNs4NHgrpEfNCBA= Received: by 10.49.8.1 with SMTP id l1mr1668729nfi; Fri, 29 Sep 2006 08:09:35 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Fri, 29 Sep 2006 08:09:35 -0700 (PDT) Message-ID: <30b660a20609290809t46e04750p9091b0184042d89b@mail.gmail.com> Date: Fri, 29 Sep 2006 08:09:35 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Re: Korean (and Japanese) In-Reply-To: <20060929034431.GH3780@ccil.org> MIME-Version: 1.0 References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> <6.0.0.20.2.20060928193237.08122670__32691.3689300001$1159440247$gmane$org@localhost> <451C66A3.52C9@xyzzy.claranet.de> <30b660a20609281824m560066c0k1202af61d673e724@mail.gmail.com> <20060929034431.GH3780@ccil.org> X-Google-Sender-Auth: 6db192f2fa955938 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0504920633==" Errors-To: ltru-bounces@ietf.org --===============0504920633== Content-Type: multipart/alternative; boundary="----=_Part_11682_1570732.1159542575292" ------=_Part_11682_1570732.1159542575292 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGFyZCB0byBtYWtlIHN1Y2ggYSBjYXRhZ29yaWNhbCBzdGF0ZW1lbnQ7IGl0IHJlYWxseSBkZXBl bmRzLiBJZiBJIHNhaWQgdGhhdAphbGwgb2YgdGhlIHRleHQgKG1lYW5pbmcgZXZlcnkgd29yZCkg aW4gdGhlIGZvbGxvd2luZyB3YXMgRW5nbGlzaCB3cml0dGVuIGluCkxhdGluLCBJIHdvdWxkIGJl IGNsZWFybHkgd3JvbmcuIElmIEkgc2FpZCB0aGF0IHRoZSBzZW50ZW5jZSB3YXMgRW5nbGlzaAp3 cml0dGVuIGluIExhdGluLCB3aXRoIHNvbWUgSmFwYW5lc2Ugd29yZHMsIEknZCBiZSByaWdodC4K CiJJbiBKYXBhbiBwZW9wbGUgd3JpdGUgaW4gKiBrYW5qaSoKKOa8ouWtlzxodHRwOi8vZW4ud2lr dGlvbmFyeS5vcmcvd2lraS8lRTYlQkMlQTIlRTUlQUQlOTc+CikiCgpNYXJrCgpPbiA5LzI4LzA2 LCBKb2huIENvd2FuIDxjb3dhbkBjY2lsLm9yZz4gd3JvdGU6Cj4KPiBNYXJrIERhdmlzIHNjcmlw c2l0Ogo+Cj4gPiBXaGF0IE1hcnRpbiB3YXMgcG9pbnRpbmcgb3V0IGlzIHRoYXQgaW4gc2l0dWF0 aW9ucyBsaWtlIHRoaXMsIEkgY2FuCj4gPiBleHRlcm5hbGx5IHZlcmlmeSBwcm9ncmFtbWF0aWNh bGx5IHRoYXQgRSBhbmQgRiBhcmUgaW5jb3JyZWN0OyBsaWJyYXJpZXMKPiA+IHRoYXQgdXNlIHRo ZSBVbmljb2RlIENoYXJhY3RlciBEYXRhYmFzZSAobGlrZSBJQ1UgYW5kIG90aGVycykgY2FuCj4g PiBkZXRlcm1pbmUgdGhhdCB0aGVyZSBhcmUgY2hhcmFjdGVycyBpbiB0aGUgc3BhbiB0aGF0IGFy ZSBub3QgSmFwbiBhbmQKPiA+IHRoZXJlIGFyZSBjaGFyYWN0ZXJzIGluIEYgdGhhdCBhcmUgbm90 IExhdG4uCj4KPiBXZWxsLCBvbmx5IHByb2JhYmlsaXN0aWNhbGx5LiAgQW4gRW5nbGlzaCB0ZXh0 IGlzIHN0aWxsIGluIExhdG4gZXZlbgo+IGlmIChsaWtlIHRoZSBvbmUgSSdtIHJlYWRpbmcgbm93 KSBpdCBjb250YWlucyB0aGUgb2NjYXNpb25hbCBHcmVlayB3b3JkCj4gaW4gdGhlIEdyZWVrIHNj cmlwdC4gIEZvciB0aGF0IG1hdHRlciwgaXQncyBzdGlsbCBpbiBFbmdsaXNoIGV2ZW4KPiB0aG91 Z2ggdGhlcmUgYXJlIG9jY2FzaW9uYWwgcXVvdGF0aW9ucyBpbiBHZXJtYW4uCj4KPiAtLQo+IFdo YXQgaXMgdGhlIHNvdW5kIG9mIFBlcmw/ICBJcyBpdCBub3QgdGhlICAgICAgIEpvaG4gQ293YW4K PiBzb3VuZCBvZiBhIFtXd11hbGwgdGhhdCBwZW9wbGUgaGF2ZSBzdG9wcGVkICAgICBjb3dhbkBj Y2lsLm9yZwo+IGJhbmdpbmcgdGhlaXIgaGVhZCBhZ2FpbnN0PyAgLS1MYXJyeSAgICAgICAgICAg IGh0dHA6Ly93d3cuY2NpbC5vcmcvfmNvd2FuPGh0dHA6Ly93d3cuY2NpbC5vcmcvJTdFY293YW4+ Cj4K ------=_Part_11682_1570732.1159542575292 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGFyZCB0byBtYWtlIHN1Y2ggYSBjYXRhZ29yaWNhbCBzdGF0ZW1lbnQ7IGl0IHJlYWxseSBkZXBl bmRzLiBJZiBJIHNhaWQgdGhhdCBhbGwgb2YgdGhlIHRleHQgKG1lYW5pbmcgZXZlcnkgd29yZCkg aW4gdGhlIGZvbGxvd2luZyB3YXMgRW5nbGlzaCB3cml0dGVuIGluIExhdGluLCBJIHdvdWxkIGJl IGNsZWFybHkgd3JvbmcuIElmIEkgc2FpZCB0aGF0IHRoZSBzZW50ZW5jZSB3YXMgRW5nbGlzaCB3 cml0dGVuIGluIExhdGluLCB3aXRoIHNvbWUgSmFwYW5lc2Ugd29yZHMsIEknZCBiZSByaWdodC4K PGJyPjxicj4mcXVvdDtJbiBKYXBhbiBwZW9wbGUgd3JpdGUgaW4gPGk+PHNwYW4gc3R5bGU9ImZv bnQtc3R5bGU6IGl0YWxpYzsiPgo8L3NwYW4+a2Fuamk8L2k+ICg8YSBocmVmPSJodHRwOi8vZW4u d2lrdGlvbmFyeS5vcmcvd2lraS8lRTYlQkMlQTIlRTUlQUQlOTciIHRpdGxlPSJ3aWt0Oua8ouWt lyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2lu ZG93LGV2ZW50LHRoaXMpIj7mvKLlrZc8L2E+KSZxdW90Ozxicj48YnI+TWFyazxicj48YnI+PGRp dj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPgpPbiA5LzI4LzA2LCA8YiBjbGFzcz0iZ21haWxf c2VuZGVybmFtZSI+Sm9obiBDb3dhbjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpjb3dhbkBjY2ls Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmso d2luZG93LGV2ZW50LHRoaXMpIj5jb3dhbkBjY2lsLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNv bGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGlu Zy1sZWZ0OiAxZXg7Ij4KCk1hcmsgRGF2aXMgc2NyaXBzaXQ6PGJyPjxicj4mZ3Q7IFdoYXQgTWFy dGluIHdhcyBwb2ludGluZyBvdXQgaXMgdGhhdCBpbiBzaXR1YXRpb25zIGxpa2UgdGhpcywgSSBj YW48YnI+Jmd0OyBleHRlcm5hbGx5IHZlcmlmeSBwcm9ncmFtbWF0aWNhbGx5IHRoYXQgRSBhbmQg RiBhcmUgaW5jb3JyZWN0OyBsaWJyYXJpZXM8YnI+Jmd0OyB0aGF0IHVzZSB0aGUgVW5pY29kZSBD aGFyYWN0ZXIgRGF0YWJhc2UgKGxpa2UgSUNVIGFuZCBvdGhlcnMpIGNhbgo8YnI+Jmd0OyBkZXRl cm1pbmUgdGhhdCB0aGVyZSBhcmUgY2hhcmFjdGVycyBpbiB0aGUgc3BhbiB0aGF0IGFyZSBub3Qg SmFwbiBhbmQ8YnI+Jmd0OyB0aGVyZSBhcmUgY2hhcmFjdGVycyBpbiBGIHRoYXQgYXJlIG5vdCBM YXRuLjxicj48YnI+V2VsbCwgb25seSBwcm9iYWJpbGlzdGljYWxseS4mbmJzcDsmbmJzcDtBbiBF bmdsaXNoIHRleHQgaXMgc3RpbGwgaW4gTGF0biBldmVuPGJyPmlmIChsaWtlIHRoZSBvbmUgSSdt IHJlYWRpbmcgbm93KSBpdCBjb250YWlucyB0aGUgb2NjYXNpb25hbCBHcmVlayB3b3JkCjxicj5p biB0aGUgR3JlZWsgc2NyaXB0LiZuYnNwOyZuYnNwO0ZvciB0aGF0IG1hdHRlciwgaXQncyBzdGls bCBpbiBFbmdsaXNoIGV2ZW48YnI+dGhvdWdoIHRoZXJlIGFyZSBvY2Nhc2lvbmFsIHF1b3RhdGlv bnMgaW4gR2VybWFuLjxicj48YnI+LS08YnI+V2hhdCBpcyB0aGUgc291bmQgb2YgUGVybD8mbmJz cDsmbmJzcDtJcyBpdCBub3QgdGhlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEpvaG4gQ293YW48YnI+c291bmQgb2YgYSBbV3ddYWxsIHRoYXQgcGVvcGxlIGhhdmUgc3RvcHBl ZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKPGEgaHJlZj0ibWFpbHRvOmNvd2FuQGNjaWwub3Jn IiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5k b3csZXZlbnQsdGhpcykiPmNvd2FuQGNjaWwub3JnPC9hPjxicj5iYW5naW5nIHRoZWlyIGhlYWQg YWdhaW5zdD8mbmJzcDsmbmJzcDstLUxhcnJ5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cDov L3d3dy5jY2lsLm9yZy8lN0Vjb3dhbiIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0 b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj4KaHR0cDovL3d3dy5jY2lsLm9y Zy9+Y293YW48L2E+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+Cgo= ------=_Part_11682_1570732.1159542575292-- --===============0504920633== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0504920633==-- From ltru-bounces@ietf.org Fri Sep 29 11:17:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTK7L-0005zm-96; Fri, 29 Sep 2006 11:17:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTK7K-0005za-5V for ltru@ietf.org; Fri, 29 Sep 2006 11:17:34 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTK7H-0003Ct-Ll for ltru@ietf.org; Fri, 29 Sep 2006 11:17:34 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1077776nfc for ; Fri, 29 Sep 2006 08:17:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=QvtjCikDoDHByVImyYcbS6fLd/UBLp+0jvbJx7jsgJkZtUJlmWNZsAkDrIovcVw9Ib4isJNdh/+zCRheQJbMWjVhrgRoHOJaQwRZmzA0qpgcvQQ8dG9G6kZwO+DaLZaFDO7K8uYSFZWtNhC+quqod8NPgM/gf5s/yclexVWkafQ= Received: by 10.49.8.1 with SMTP id l1mr5259997nfi; Fri, 29 Sep 2006 08:17:30 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Fri, 29 Sep 2006 08:17:30 -0700 (PDT) Message-ID: <30b660a20609290817pac596dqe45f74c657f1b9ed@mail.gmail.com> Date: Fri, 29 Sep 2006 08:17:30 -0700 From: "Mark Davis" To: "Mark Crispin" In-Reply-To: MIME-Version: 1.0 References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> <6.0.0.20.2.20060928193237.08122670@localhost> X-Google-Sender-Auth: c9a06720880c6bde X-Spam-Score: 0.5 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ietf-languages@iana.org, LTRU Working Group Subject: [Ltru] Re: Korean (and Japanese) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1587886968==" Errors-To: ltru-bounces@ietf.org --===============1587886968== Content-Type: multipart/alternative; boundary="----=_Part_11818_16372754.1159543050309" ------=_Part_11818_16372754.1159543050309 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline A more realistic (but still, of course, somewhat contrived) example would be: "He didn't do it for her beer, he did it for her sake." It could be interpreted in two ways, depending on whether "sake" was read as /sek/ or as /sake/. But, of course, the same thing could happen with two native English words that happen to have different pronunciations, where language tags wouldn't help to disambiguate. And when push comes to shove, only in extremely rare instances will people tag language on a very fine grained level. Frankly, at Google we end up having to basically disregard language tagging of web pages because it is so, so often wrong. Mark On 9/28/06, Mark Crispin wrote: > > On Thu, 28 Sep 2006, Martin Duerst wrote: > > On that level, the main usages of the information > > are e.g. for text-to-speach. What you want is that your name > > is pronounced in the Japanese way rather than the way an > > English (or some other language) speaker would pronounce it. > > The characters are there in the data, so tagging the script > > would actually be overkill, either redundant or contradictory. > > Interesting point. > > So I assume that means that "karaoke" tagged as ja-Latn would be > pronounced (somewhat like "kah-rah-oh-kay" to an English speaker), whereas > "karaoke" tagged as "en" would be pronounced as "kerry-oh-key"? :-) > > -- Mark -- > > http://panda.com/mrc > Democracy is two wolves and a sheep deciding what to eat for lunch. > Liberty is a well-armed sheep contesting the vote. > _______________________________________________ > Ietf-languages mailing list > Ietf-languages@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/ietf-languages > ------=_Part_11818_16372754.1159543050309 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline A more realistic (but still, of course, somewhat contrived) example would be:

"He didn't do it for her beer, he did it for her sake."

It could be interpreted in two ways, depending on whether "sake" was read as /sek/ or as /sake/. But, of course, the same thing could happen with two native English words that happen to have different pronunciations, where language tags wouldn't help to disambiguate.

And when push comes to shove, only in extremely rare instances will people tag language on a very fine grained level. Frankly, at Google we end up having to basically disregard language tagging of web pages because it is so, so often wrong.

Mark

On 9/28/06, Mark Crispin <mrc@cac.washington.edu> wrote:
On Thu, 28 Sep 2006, Martin Duerst wrote:
> On that level, the main usages of the information
> are e.g. for text-to-speach. What you want is that your name
> is pronounced in the Japanese way rather than the way an
> English (or some other language) speaker would pronounce it.
> The characters are there in the data, so tagging the script
> would actually be overkill, either redundant or contradictory.

Interesting point.

So I assume that means that "karaoke" tagged as ja-Latn would be
pronounced (somewhat like "kah-rah-oh-kay" to an English speaker), whereas
"karaoke" tagged as "en" would be pronounced as "kerry-oh-key"?  :-)

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Ietf-languages mailing list
Ietf-languages@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages

------=_Part_11818_16372754.1159543050309-- --===============1587886968== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1587886968==-- From ltru-bounces@ietf.org Fri Sep 29 11:45:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTKXr-0006ft-UQ; Fri, 29 Sep 2006 11:44:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTKXq-0006db-Qe for ltru@ietf.org; Fri, 29 Sep 2006 11:44:58 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTKXo-0007y3-Hm for ltru@ietf.org; Fri, 29 Sep 2006 11:44:58 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GTKXo-0002u4-8p; Fri, 29 Sep 2006 11:44:56 -0400 Date: Fri, 29 Sep 2006 11:44:56 -0400 To: Mark Davis Subject: Re: [Ltru] Re: Korean (and Japanese) Message-ID: <20060929154456.GD22895@ccil.org> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> <6.0.0.20.2.20060928193237.08122670__32691.3689300001$1159440247$gmane$org@localhost> <451C66A3.52C9@xyzzy.claranet.de> <30b660a20609281824m560066c0k1202af61d673e724@mail.gmail.com> <451C899C.3C0E@xyzzy.claranet.de> <30b660a20609290740nc2c3f8bp7985c80202a7d7f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20609290740nc2c3f8bp7985c80202a7d7f@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > This is untrue. I need no licence to tag anything as simply 'ja' (instead of > ja-), if that's all I want to tag it with. Quite so. The point of Suppress-Script: is to discourage pointless "ja-Jpan" tags, because they damage the language-tag ecology. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Assent may be registered by a signature, a handshake, or a click of a computer mouse transmitted across the invisible ether of the Internet. Formality is not a requisite; any sign, symbol or action, or even willful inaction, as long as it is unequivocally referable to the promise, may create a contract. --Specht v. Netscape _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 11:51:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTKeG-00020b-GJ; Fri, 29 Sep 2006 11:51:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTKeF-000204-JD for ltru@ietf.org; Fri, 29 Sep 2006 11:51:35 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTKeE-000096-6y for ltru@ietf.org; Fri, 29 Sep 2006 11:51:35 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7]) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8TFpQVH001510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Sep 2006 08:51:26 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8TFpPVK011211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Sep 2006 08:51:26 -0700 Date: Fri, 29 Sep 2006 08:51:24 -0700 (PDT) From: Mark Crispin To: Mark Davis In-Reply-To: <30b660a20609290817pac596dqe45f74c657f1b9ed@mail.gmail.com> Message-ID: References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> <6.0.0.20.2.20060928193237.08122670@localhost> <30b660a20609290817pac596dqe45f74c657f1b9ed@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.266434, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.9.29.82442 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __FRAUD_419_CONTACT 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ietf-languages@iana.org, LTRU Working Group Subject: [Ltru] Re: Korean (and Japanese) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, 29 Sep 2006, Mark Davis wrote: > A more realistic (but still, of course, somewhat contrived) example would > be: > "He didn't do it for her beer, he did it for her sake." Indeed. There is a joke about a sansei named Peter Yamamoto who decided to brew sake here in the US, and how people would do anything for Pete's sake... > And when push comes to shove, only in extremely rare instances will people > tag language on a very fine grained level. Frankly, at Google we end up > having to basically disregard language tagging of web pages because it is > so, so often wrong. I agree. It isn't just language tagging. Charset tagging is often also wrong. Some people are under the mistaken impression that the way to tag "8-bit content" is to set charset to ISO-8859-1, even though the actual content is Korean, etc. For what it's worth, I just got private email from the mighty Morfin power ranger. I sent back a sharp response telling him not to send me any more email. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 12:35:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTLKE-0005IZ-L6; Fri, 29 Sep 2006 12:34:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTLKE-0005HI-25 for ltru@ietf.org; Fri, 29 Sep 2006 12:34:58 -0400 Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime01.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTLFC-000565-Ez for ltru@ietf.org; Fri, 29 Sep 2006 12:29:47 -0400 Received: from eupig2 (unverified [129.1.30.40]) by lonsmime01.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Fri, 29 Sep 2006 16:29:44 +0000 Received: from lonsmsxb01.emea.ime.reuters.com ([10.14.113.6]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31217) with ESMTP id <0J6D003A14HKPB@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Fri, 29 Sep 2006 16:29:44 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Fri, 29 Sep 2006 17:29:44 +0100 Date: Fri, 29 Sep 2006 17:28:47 +0100 From: Misha Wolf Subject: RE: [Ltru] Re-use of a region code for the same purpose [was: Re: ISO 3166-1 newsletter on Serbia and Montenegro] To: ltru@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Re-use of a region code for the same purpose [was: Re: ISO 3166-1 newsletter on Serbia and Montenegro] Thread-Index: AcbjzTBnxMlGPc2uTTCP2v4/CZHGOgAFve0g Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 29 Sep 2006 16:29:44.0483 (UTC) FILETIME=[78C47F30:01C6E3E4] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > If a unification re-created a former country exactly, we=20 > might bend our rules, I suppose.=20 So how about making sure that RFC 4646bis allows us to do=20 this without rule-bending? Misha This email was sent to you by Reuters, the global news and information comp= any.=20 To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 12:40:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTLPz-0001jI-3R; Fri, 29 Sep 2006 12:40:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTLPx-0001fl-84 for ltru@ietf.org; Fri, 29 Sep 2006 12:40:53 -0400 Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTLPv-0007A5-Sg for ltru@ietf.org; Fri, 29 Sep 2006 12:40:53 -0400 Received: from eupig2 (unverified [129.1.30.40]) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Fri, 29 Sep 2006 16:40:50 +0000 Received: from LONSMSXB02.emea.ime.reuters.com ([10.14.113.7]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31217) with ESMTP id <0J6D008RH502M2@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Fri, 29 Sep 2006 16:40:50 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by LONSMSXB02.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Fri, 29 Sep 2006 17:40:47 +0100 Date: Fri, 29 Sep 2006 17:39:22 +0100 From: Misha Wolf Subject: RE: [Ltru] Re: Korean (and Japanese) To: ltru@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Re: Korean (and Japanese) Thread-Index: Acbj3kCTcIIUVgq6SVuoIKexqI1magABrxNA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 29 Sep 2006 16:40:47.0208 (UTC) FILETIME=[03C84E80:01C6E3E6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > Quite so. The point of Suppress-Script: is to discourage=20 > pointless "ja-Jpan" tags, because they damage the language-tag=20 > ecology.=20 As I may have mentioned previously, for some Japanese data,=20 we hold two versions: one using the full mix of scripts and=20 one using Katakana. My current intention is that an API call=20 specifying ja-Jpan will return just the former, one specifying=20 ja-Kana will return just the latter, and one specifying ja=20 will return whatever is available. I know that doesn't quite=20 square with the discussion here, but I can't see another way=20 to do it. Misha This email was sent to you by Reuters, the global news and information comp= any.=20 To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 13:31:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMCP-0001BX-TY; Fri, 29 Sep 2006 13:30:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMCN-00019o-Uk for ltru@ietf.org; Fri, 29 Sep 2006 13:30:55 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTMCL-0000E2-Lx for ltru@ietf.org; Fri, 29 Sep 2006 13:30:55 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GTMCL-00066n-1K; Fri, 29 Sep 2006 13:30:53 -0400 Date: Fri, 29 Sep 2006 13:30:52 -0400 To: Misha Wolf Subject: Re: [Ltru] Re: Korean (and Japanese) Message-ID: <20060929173052.GF22895@ccil.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Misha Wolf scripsit: > > Quite so. The point of Suppress-Script: is to discourage > > pointless "ja-Jpan" tags, because they damage the language-tag > > ecology. > > As I may have mentioned previously, for some Japanese data, > we hold two versions: one using the full mix of scripts and > one using Katakana. My current intention is that an API call > specifying ja-Jpan will return just the former, one specifying > ja-Kana will return just the latter, and one specifying ja > will return whatever is available. I know that doesn't quite > square with the discussion here, but I can't see another way > to do it. Fair enough; I was just using that as an example, and it may well be a bad one. (_The Tale of Genji_ is IIRC in jp-Hira.) -- First known example of political correctness: John Cowan After Nurhachi had united all the other http://www.ccil.org/~cowan Jurchen tribes under the leadership of the cowan@ccil.org Manchus, his successor Abahai (1592-1643) issued an order that the name Jurchen should --S. Robert Ramsey, be banned, and from then on, they were all The Languages of China to be called Manchus. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 15:37:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTOB6-00076b-Bh; Fri, 29 Sep 2006 15:37:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTOB5-00072h-Cd for ltru@ietf.org; Fri, 29 Sep 2006 15:37:43 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTOB1-0007gr-5k for ltru@ietf.org; Fri, 29 Sep 2006 15:37:43 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GTOB0-0001Y9-JK; Fri, 29 Sep 2006 15:37:38 -0400 Date: Fri, 29 Sep 2006 15:37:38 -0400 To: Doug Ewell Subject: Re: [Ltru] Submission: draft-ietf-ltru-4645bis-00 Message-ID: <20060929193738.GD28837@ccil.org> References: <00f901c6e399$643dc8f0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00f901c6e399$643dc8f0$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > o If the language was included within a macrolanguage, an extended "encompassed by a macrolanguage" is the style used by 639-3. > Because it does not represent a useful linguistic > distinction for tagging purposes, it was deprecated without a > Preferred-Value. Better to be less forthright: "Because it is not believed to represent". > This document specifies the complete updated contents to be used by > IANA in populating the Language Subtag Registry. "a complete replacement of the contents of the LSR to be used by IANA in updating it" makes it clear that this isn't just a complete (as opposed to partial) *update*, it *replaces* what came before. > In its initial phase as an Internet-Draft, this memo contained the > complete updated contents of the Language Subtag Registry. As an Same story. > RFC, it contains a pointer to the updated content for the Registry, Just "pointer to the Registry". I may have more comments later. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Humpty Dump Dublin squeaks through his norse Humpty Dump Dublin hath a horrible vorse But for all his kinks English / And his irismanx brogues Humpty Dump Dublin's grandada of all rogues. --Cousin James _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 17:39:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTQ4u-0002W2-1y; Fri, 29 Sep 2006 17:39:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTQ4t-0002Vx-DA for ltru@ietf.org; Fri, 29 Sep 2006 17:39:27 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTQ4s-0000sN-4d for ltru@ietf.org; Fri, 29 Sep 2006 17:39:27 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GTQ4r-0007C5-8t; Fri, 29 Sep 2006 17:39:25 -0400 Date: Fri, 29 Sep 2006 17:39:25 -0400 To: Addison Phillips Message-ID: <20060929213924.GG28837@ccil.org> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <451ACCC5.6010609@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <451ACCC5.6010609@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ltru@ietf.org Subject: [Ltru] Suppress-script considered least harmful X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > It is exactly why Suppress-Script is an awful solution to the problem of > preventing unwanted script subtags. Too much information is required > about too many languages. Most languages are customarily written in only > one script, but determining which ones that is true of and what the > script subtag should be is moderately difficult, especially for > languages of limited diffusion. > > By contrast, determining which small number of languages are customarily > written in more than one script (Note Well: the word 'customarily'!) is > a far easier task. The trouble is, what's the alternative? If we went to an Accept-Script: header specifying a script that works with multiscript languages like az, then we have two possible tacks: a) If there are no Accept-Script headers, no script subtags can be used. b) If there are no Accept-Script headers, any script subtag can be used. The trouble with (a) is that it defeats the generativity that was one of the main purposes of RFC 4646. Instead of just being able to tag your Cyrillic orthography for Irish as "ga-Cyrl", you have to come to us hat in hand and ask for it to be registered. Bad. The trouble with (b) is that it's not monotonic. If we learn that 'aa' is often written in 'Aaaa', and we add it to the registry, then the formerly valid tag "aa-Zzzz" becomes invalid. Very, very bad, particularly if "aa-Zzzz" is already in use in the wild. What's more, almost any language that can be written at all, can be written in alternative scripts on some occasions. 'Latn' and 'Brai' are notable candidates. So we end up having to provide Accept-Script: headers for most languages anyhow. > It took a lot of work to arrive at [the Korean] conclusion, no? Why > are these other languages different? Because Korean is an edge case: it has moved from complete use of Han script to a position where Hangul is almost always used but there are a few domains where Han is still required. In South Korea, at least, one must still learn a limited number of Han characters to be considered literate. There is nothing comparable for English or French or German or Igbo or Hebrew. I'm happy to keep Suppress-Script confined (as a matter of administrative policy, not RFC 4646bis rule) to the languages of 639-1 and 639-2. -- In politics, obedience and support John Cowan are the same thing. --Hannah Arendt http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 29 18:03:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTQSH-0001fq-28; Fri, 29 Sep 2006 18:03:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTQSF-0001fL-CF for ltru@ietf.org; Fri, 29 Sep 2006 18:03:35 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTQS9-00069q-NT for ltru@ietf.org; Fri, 29 Sep 2006 18:03:35 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1175936nfc for ; Fri, 29 Sep 2006 15:03:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=e/byCT+nweq8MsAzgZXD0a0kcNQAMVDzUCUjFSwmIojfgXFfMkDwDvwxWh6g672c86M0LoG5DqXI3VY61ysjslp2Ep3tvKAgo4TZ7gZRG9JICqtTjQW8eQ62e9op17WpU1vTqgIuY8TSy4U6+GXrLTcxyUGs4FalmeMxAWGzKpo= Received: by 10.49.80.12 with SMTP id h12mr5864925nfl; Fri, 29 Sep 2006 15:03:28 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Fri, 29 Sep 2006 15:03:28 -0700 (PDT) Message-ID: <30b660a20609291503v7b3ed262icb0365d122f57226@mail.gmail.com> Date: Fri, 29 Sep 2006 15:03:28 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Suppress-script considered least harmful In-Reply-To: <20060929213924.GG28837@ccil.org> MIME-Version: 1.0 References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <451ACCC5.6010609@yahoo-inc.com> <20060929213924.GG28837@ccil.org> X-Google-Sender-Auth: 909968652ea8e445 X-Spam-Score: 0.5 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0495467181==" Errors-To: ltru-bounces@ietf.org --===============0495467181== Content-Type: multipart/alternative; boundary="----=_Part_20817_17837128.1159567408551" ------=_Part_20817_17837128.1159567408551 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline If I had had my druthers, we would have had a tag that said (perhaps in nicer language): Commonly-Multiscript: Yes We would have marked just those languages that are commonly written with multiple scripts. That is enough of a signal to people that they don't need to add script to other language subtags. That is enough information to solve the compatibility problem ("Which language tags might I normally need to put a script tag on."). If we wanted to supply just a bit more useful information, it would be possible to change that slightly to actually name the scripts, with most commonly used script first. Common-Scripts: Hans, Hant > If we learn that > 'aa' is often written in 'Aaaa', and we add it to the registry, then > the formerly valid tag "aa-Zzzz" becomes invalid. Like the current Suppress-Script, *none* of this is a matter of validity. Any combination of valid language tag and valid script tag is valid; it is just that certain combinations are discouraged in general use. Mark On 9/29/06, John Cowan wrote: > > Addison Phillips scripsit: > > > It is exactly why Suppress-Script is an awful solution to the problem of > > preventing unwanted script subtags. Too much information is required > > about too many languages. Most languages are customarily written in only > > one script, but determining which ones that is true of and what the > > script subtag should be is moderately difficult, especially for > > languages of limited diffusion. > > > > By contrast, determining which small number of languages are customarily > > written in more than one script (Note Well: the word 'customarily'!) is > > a far easier task. > > The trouble is, what's the alternative? If we went to an Accept-Script: > header specifying a script that works with multiscript languages like > az, then we have two possible tacks: > > a) If there are no Accept-Script headers, no script subtags can be used. > > b) If there are no Accept-Script headers, any script subtag can be used. > > The trouble with (a) is that it defeats the generativity that was one > of the main purposes of RFC 4646. Instead of just being able to tag > your Cyrillic orthography for Irish as "ga-Cyrl", you have to come to > us hat in hand and ask for it to be registered. Bad. > > The trouble with (b) is that it's not monotonic. If we learn that > 'aa' is often written in 'Aaaa', and we add it to the registry, then > the formerly valid tag "aa-Zzzz" becomes invalid. Very, very bad, > particularly if "aa-Zzzz" is already in use in the wild. > > What's more, almost any language that can be written at all, can be > written in alternative scripts on some occasions. 'Latn' and 'Brai' > are notable candidates. So we end up having to provide Accept-Script: > headers for most languages anyhow. > > > It took a lot of work to arrive at [the Korean] conclusion, no? Why > > are these other languages different? > > Because Korean is an edge case: it has moved from complete use of Han > script to a position where Hangul is almost always used but there are > a few domains where Han is still required. In South Korea, at least, > one must still learn a limited number of Han characters to be > considered literate. There is nothing comparable for English or > French or German or Igbo or Hebrew. > > I'm happy to keep Suppress-Script confined (as a matter of administrative > policy, not RFC 4646bis rule) to the languages of 639-1 and 639-2. > > -- > In politics, obedience and support John Cowan > are the same thing. --Hannah Arendt http://www.ccil.org/~cowan > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_20817_17837128.1159567408551 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline If I had had my druthers, we would have had a tag that said (perhaps in nicer language):

Commonly-Multiscript: Yes

We would have marked just those languages that are commonly written with multiple scripts. That is enough of a signal to people that they don't need to add script to other language subtags. That is enough information to solve the compatibility problem ("Which language tags might I normally need to put a script tag on."). If we wanted to supply just a bit more useful information, it would be possible to change that slightly to actually name the scripts, with most commonly used script first.

Common-Scripts: Hans, Hant

> If we learn that
> 'aa' is often written in 'Aaaa', and we add it to the registry, then
> the formerly valid tag "aa-Zzzz" becomes invalid.

Like the current Suppress-Script, *none* of this is a matter of validity. Any combination of valid language tag and valid script tag is valid; it is just that certain combinations are discouraged in general use.

Mark

On 9/29/06, John Cowan <cowan@ccil.org> wrote:
Addison Phillips scripsit:

> It is exactly why Suppress-Script is an awful solution to the problem of
> preventing unwanted script subtags. Too much information is required
> about too many languages. Most languages are customarily written in only
> one script, but determining which ones that is true of and what the
> script subtag should be is moderately difficult, especially for
> languages of limited diffusion.
>
> By contrast, determining which small number of languages are customarily
> written in more than one script (Note Well: the word 'customarily'!) is
> a far easier task.

The trouble is, what's the alternative?  If we went to an Accept-Script:
header specifying a script that works with multiscript languages like
az, then we have two possible tacks:

a) If there are no Accept-Script headers, no script subtags can be used.

b) If there are no Accept-Script headers, any script subtag can be used.

The trouble with (a) is that it defeats the generativity that was one
of the main purposes of RFC 4646.  Instead of just being able to tag
your Cyrillic orthography for Irish as "ga-Cyrl", you have to come to
us hat in hand and ask for it to be registered.  Bad.

The trouble with (b) is that it's not monotonic.  If we learn that
'aa' is often written in 'Aaaa', and we add it to the registry, then
the formerly valid tag "aa-Zzzz" becomes invalid.  Very, very bad,
particularly if "aa-Zzzz" is already in use in the wild.

What's more, almost any language that can be written at all, can be
written in alternative scripts on some occasions.  'Latn' and 'Brai'
are notable candidates.  So we end up having to provide Accept-Script:
headers for most languages anyhow.

> It took a lot of work to arrive at [the Korean] conclusion, no? Why
> are these other languages different?

Because Korean is an edge case: it has moved from complete use of Han
script to a position where Hangul is almost always used but there are
a few domains where Han is still required.  In South Korea, at least,
one must still learn a limited number of Han characters to be
considered literate.  There is nothing comparable for English or
French or German or Igbo or Hebrew.

I'm happy to keep Suppress-Script confined (as a matter of administrative
policy, not RFC 4646bis rule) to the languages of 639-1 and 639-2.

--
In politics, obedience and support      John Cowan < cowan@ccil.org>
are the same thing.  --Hannah Arendt    http://www.ccil.org/~cowan

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

------=_Part_20817_17837128.1159567408551-- --===============0495467181== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0495467181==-- From ltru-bounces@ietf.org Fri Sep 29 19:16:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTRb3-0004Q8-5a; Fri, 29 Sep 2006 19:16:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTRb1-0004I2-DK for ltru@ietf.org; Fri, 29 Sep 2006 19:16:43 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound2-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTRav-0006yO-JA for ltru@ietf.org; Fri, 29 Sep 2006 19:16:43 -0400 Received: from outbound2-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-cpk-R.bigfish.com (Postfix) with ESMTP id 490F37440FA; Fri, 29 Sep 2006 23:16:30 +0000 (UTC) Received: from mail82-cpk-R.bigfish.com (unknown [192.168.21.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound2-cpk.bigfish.com (Postfix) with ESMTP id 40C52743F02; Fri, 29 Sep 2006 23:16:30 +0000 (UTC) Received: from mail82-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail82-cpk-R.bigfish.com (Postfix) with ESMTP id 24F8B5B86C4; Fri, 29 Sep 2006 23:16:30 +0000 (UTC) X-BigFish: VP Received: by mail82-cpk (MessageSwitch) id 115957179044867_29945; Fri, 29 Sep 2006 23:16:30 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail82-cpk.bigfish.com (Postfix) with ESMTP id E73105B84F2; Fri, 29 Sep 2006 23:16:29 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2006092916192724-1690603 ; Fri, 29 Sep 2006 16:19:27 -0700 In-Reply-To: <6.0.0.20.2.20060928104743.098b7df0@localhost> To: Martin Duerst Subject: Re: [Ltru] Re: Suppress-Script batch 1 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 From: Karen_Broome@spe.sony.com Message-ID: Date: Fri, 29 Sep 2006 16:15:16 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 09/29/2006 16:15:18, Serialize complete at 09/29/2006 16:15:18, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 09/29/2006 04:19:27 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 09/29/2006 04:19:29 PM, Serialize complete at 09/29/2006 04:19:29 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1246198640==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1246198640== Content-Type: multipart/alternative; boundary="=_alternative 007BB409882571F8_=" This is a multipart message in MIME format. --=_alternative 007BB409882571F8_= Content-Type: text/plain; charset="US-ASCII" Changes to clarify use of script tags and RFC 4646bis with spoken language: -Section 1- "In addition, knowledge about the particular language used by some piece of information content might be useful or even required by some types of processing; for example, spell-checking, computer- synthesized speech, Braille transcription, or high-quality print renderings." ADD after previous paragraph? It is important to note that the language identification needs described above apply not only to written language, but also to spoken language such that found in videos, audio files, songs, podcasts, films, and written interfaces used to access or classify such content. -Section 2.2.3- Changes: 2. When applicable, 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. ADD: 6. Script subtags MUST NOT be used to identify language that is spoken or sung. Script tags and Suppress-Script fields are not applicable to such content. -Section 4.1- 2. ... * For example, the subtag '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 document were written in English mixing Latin script with another script such as Braille ('Brai'), then it might be appropriate to choose to indicate both scripts to aid in content selection, such as the application of a style sheet. On the other hand, the subtags 'Hant' and 'Hans' should not be used to describe an audiovisual asset in Chinese unless the language appears in written subtitles or captions. I'm still checking to see if there are any other opportunities for clarification. Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 Martin Duerst 09/27/2006 06:48 PM To Karen_Broome@spe.sony.com, "Doug Ewell" , "LTRU Working Group" cc Subject Re: [Ltru] Re: Suppress-Script batch 1 Hello Karen, As a technical contributor, I think you raise a very valid point that should be documented clearly. As a co-chair, I'd like to ask you to propose specific wording, and a place to put it. This is the fastest way to move this issue forward. Regards, Martin. At 02:52 06/09/28, Karen_Broome@spe.sony.com wrote: >I still think the text of RFC 4646 and structure leans strongly toward an assumption that all language is written. Increasingly web content features animated talking heads or video, and this content may need language tagging as well. > >Motion picture applications -- including television, broadcast, Digital Cinema, podcast, phonecast, multilingual electronic program guides, and local/national/university archives -- also require language tagging. The text of RFC 4646 indicates that the script can be omitted when it can be assumed. It doesn't mention that in an increasing number of cases, the assignment of a script tag is completely inappropriate. > >Regards, > >Karen Broome >Metadata Systems Designer >Sony Pictures Entertainment > > > > > >"Doug Ewell" > >09/27/2006 10:15 AM >To >"LTRU Working Group" >cc >Subject >[Ltru] Re: Suppress-Script batch 1 > > > > >John Cowan wrote: > >> Remember that the criterion for including a Suppress-Script is that >> the script is always used for the language except in a few highly >> restricted domains, such as writing for the blind, scholarly >> transliteration, transcription for use in another language, and when >> the standard script is not available. > >I wish we had that explanation somewhere in RFC 4646. It's better than >most of the explanations I've seen, certainly better than any I've >written. > >-- >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 >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aFrom ltru-bounces@ietf.org Fri Sep 29 19:16:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTRb3-0004Q8-5a; Fri, 29 Sep 2006 19:16:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTRb1-0004I2-DK for ltru@ietf.org; Fri, 29 Sep 2006 19:16:43 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound2-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTRav-0006yO-JA for ltru@ietf.org; Fri, 29 Sep 2006 19:16:43 -0400 Received: from outbound2-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-cpk-R.bigfish.com (Postfix) with ESMTP id 490F37440FA; Fri, 29 Sep 2006 23:16:30 +0000 (UTC) Received: from mail82-cpk-R.bigfish.com (unknown [192.168.21.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound2-cpk.bigfish.com (Postfix) with ESMTP id 40C52743F02; Fri, 29 Sep 2006 23:16:30 +0000 (UTC) Received: from mail82-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail82-cpk-R.bigfish.com (Postfix) with ESMTP id 24F8B5B86C4; Fri, 29 Sep 2006 23:16:30 +0000 (UTC) X-BigFish: VP Received: by mail82-cpk (MessageSwitch) id 115957179044867_29945; Fri, 29 Sep 2006 23:16:30 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail82-cpk.bigfish.com (Postfix) with ESMTP id E73105B84F2; Fri, 29 Sep 2006 23:16:29 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2006092916192724-1690603 ; Fri, 29 Sep 2006 16:19:27 -0700 In-Reply-To: <6.0.0.20.2.20060928104743.098b7df0@localhost> To: Martin Duerst Subject: Re: [Ltru] Re: Suppress-Script batch 1 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 From: Karen_Broome@spe.sony.com Message-ID: Date: Fri, 29 Sep 2006 16:15:16 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 09/29/2006 16:15:18, Serialize complete at 09/29/2006 16:15:18, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 09/29/2006 04:19:27 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 09/29/2006 04:19:29 PM, Serialize complete at 09/29/2006 04:19:29 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1246198640==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1246198640== Content-Type: multipart/alternative; boundary="=_alternative 007BB409882571F8_=" This is a multipart message in MIME format. --=_alternative 007BB409882571F8_= Content-Type: text/plain; charset="US-ASCII" Changes to clarify use of script tags and RFC 4646bis with spoken language: -Section 1- "In addition, knowledge about the particular language used by some piece of information content might be useful or even required by some types of processing; for example, spell-checking, computer- synthesized speech, Braille transcription, or high-quality print renderings." ADD after previous paragraph? It is important to note that the language identifioyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 007BB409882571F8_= Content-Type: text/html; charset="US-ASCII"
Changes to clarify use of script tags and RFC 4646bis with spoken language:

-Section 1-

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

ADD after previous paragraph?

It is important to note that the language identification needs described above apply not only to written language, but also to spoken language such that found in videos, audio files, songs, podcasts, films, and written interfaces used to access or classify such content.

-Section 2.2.3-

Changes:

2.  <ADD>When applicable,</ADD> 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.

ADD:

   6.  Script subtags MUST NOT be used to identify language that is spoken or sung. Script                   tags and Suppress-Script fields are not applicable to such content.

-Section 4.1-

2.  ...

*  For example, the subtag '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 document were written in English mixing Latin script with another script such as Braille ('Brai'), then it might be appropriate to choose to indicate
both scripts to aid in content selection, such as the application of a style sheet. <ADD> On the other hand, the subtags 'Hant' and 'Hans' should not be used to describe an audiovisual asset in Chinese unless the language appears in written subtitles or captions.</ADD>

I'm still checking to see if there are any other opportunities for clarification.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384




Martin Duerst <duerst@it.aoyama.ac.jp>

09/27/2006 06:48 PM

To
Karen_Broome@spe.sony.com, "Doug Ewell" <dewell@adelphia.net>, "LTRU Working Group" <ltru@ietf.org>
cc
Subject
Re: [Ltru] Re: Suppress-Script batch 1





Hello Karen,

As a technical contributor, I think you raise a very valid
point that should be documented clearly.

As a co-chair, I'd like to ask you to propose specific wording,
and a place to put it. This is the fastest way to move this
issue forward.

Regards,    Martin.
When applicable, 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. ADD: 6. Script subtags MUST NOT be used to identify language that is spoken or sung. Script tags and Suppress-Script fields are not applicable to such content. -Section 4.1- 2. ... * For example, the subtag '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 document were written in English mixing Latin script with another script such as Braille ('Brai'), then it might be appropriate to choose to indicate both scripts to aid in content selection, such as the application of a style sheet. On the other hand, the subtags 'Hant' and 'Hans' should not be used to describe an audiovisual asset in Chinese unless the language appears in written subtitles or captions. I'm still checking to see if there are any other opportunities for clarification. Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 Martin Duerst 09/27/2006 06:48 PM To Karen_Broome@spe.sony.com, "Doug Ewell" , "LTRU Working Group" cc Subject Re: [Ltru] Re: Suppress-Script batch 1 Hello Karen, As a technical contributor, I think you raise a very valid point that should be documented clearly. As a co-chair, I'd like to ask you to propose specific wording, and a place to put it. This is the fastest way to move this issue forward. Regards, Martin. At 02:52 06/09/28, Karen_Broome@spe.sony.com wrote: >I still think the text of RFC 4646 and structure leans strongly toward an assumption that all language is written. Increasingly web content features animated talking heads or video, and this content may need language tagging as well. > >Motion picture applications -- including television, broadcast, Digital Cinema, podcast, phonecast, multilingual electronic program guides, and local/national/university archives -- also require language tagging. The text of RFC 4646 indicates that the script can be omitted when it can be assumed. It doesn't mention that in an increasing number of cases, the assignment of a script tag is completely inappropriate. > >Regards, > >Karen Broome >Metadata Systems Designer >Sony Pictures Entertainment > > > > > >"Doug Ewell" > >09/27/2006 10:15 AM >To >"LTRU Working Group" >cc >Subject >[Ltru] Re: Suppress-Script batch 1 > > > > >John Cowan wrote: > >> Remember that the criterion for including a Suppress-Script is that >> the script is always used for the language except in a few highly >> restricted domains, such as writing for the blind, scholarly >> transliteration, transcription for use in another language, and when >> the standard script is not available. > >I wish we had that explanation somewhere in RFC 4646. It's better than >most of the explanations I've seen, certainly better than any I've >written. > >-- >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 >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.a> At 02:52 06/09/28, Karen_Broome@spe.sony.com wrote:

>I still think the text of RFC 4646 and structure leans strongly toward an assumption that all language is written. Increasingly web content features animated talking heads or video, and this content may need language tagging as well.
>
>Motion picture applications -- including television, broadcast, Digital Cinema, podcast, phonecast, multilingual electronic program guides, and local/national/university archives -- also require language tagging. The text of RFC 4646 indicates that the script can be omitted when it can be assumed. It doesn't mention that in an increasing number of cases, the assignment of a script tag is completely inappropriate.
>
>Regards,
>
>Karen Broome
>Metadata Systems Designer
>Sony Pictures Entertainment
>
>
>
>
>
>"Doug Ewell" <dewell@adelphia.net>
>
>09/27/2006 10:15 AM
>To
>"LTRU Working Group" <ltru@ietf.org>
>cc
>Subject
>[Ltru] Re: Suppress-Script batch 1
>
>
>
>
>John Cowan <cowan at ccil dot org> wrote:
>
>> Remember that the criterion for including a Suppress-Script is that
>> the script is always used for the language except in a few highly
>> restricted domains, such as writing for the blind, scholarly
>> transliteration, transcription for use in another language, and when
>> the standard script is not available.
>
>I wish we had that explanation somewhere in RFC 4646.  It's better than
>most of the explanations I've seen, certainly better than any I've
>written.
>
>--
>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
>Ltru@ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru
>
>
>_______________________________________________
>Ltru mailing list
>Ltru@ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


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


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 007BB409882571F8_=-- --===============1246198640== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1246198640==-- From ltru-bounces@ietf.org Fri Sep 29 19:16:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTRb0-0004Et-R9; Fri, 29 Sep 2006 19:16:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTRaz-0004CA-IN for ltru@ietf.org; Fri, 29 Sep 2006 19:16:41 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound2-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTRav-0006yH-Ha for ltru@ietf.org; Fri, 29 Sep 2006 19:16:41 -0400 Received: from outbound2-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-cpk-R.bigfish.com (Postfix) with ESMTP id F37147440F6 for ; Fri, 29 Sep 2006 23:16:28 +0000 (UTC) Received: from mail24-cpk-R.bigfish.com (unknown [192.168.21.3]) (using TLSv1 with cipher EDH-RSA-DES-Coyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 007BB409882571F8_= Content-Type: text/html; charset="US-ASCII"
Changes to clarify use of script tags and RFC 4646bis with spoken language:

-Section 1-

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

ADD after previous paragraph?

It is important to note that the language identification needs described above apply not only to written language, but also to spoken language such that found in videos, audio files, songs, podcasts, films, and written interfaces used to access or classify such content.

-Section 2.2.3-

Changes:

2.  <ADD>When applicable,</ADD> 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.

ADD:

   6.  Script subtags MUST NOT be used to identify language that is spoken or sung. Script                   tags and Suppress-Script fields are not applicable to such content.

-Section 4.1-

2.  ...

*  For example, the subtag '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 document were written in English mixing Latin script with another script such as Braille ('Brai'), then it might be appropriate to choose to indicate
both scripts to aid in content selection, such as the application of a style sheet. <ADD> On the other hand, the subtags 'Hant' and 'Hans' should not be used to describe an audiovisual asset in Chinese unless the language appears in written subtitles or captions.</ADD>

I'm still checking to see if there are any other opportunities for clarification.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384




Martin Duerst <duerst@it.aoyama.ac.jp>

09/27/2006 06:48 PM

To
Karen_Broome@spe.sony.com, "Doug Ewell" <dewell@adelphia.net>, "LTRU Working Group" <ltru@ietf.org>
cc
Subject
Re: [Ltru] Re: Suppress-Script batch 1





Hello Karen,

As a technical contributor, I think you raise a very valid
point that should be documented clearly.

As a co-chair, I'd like to ask you to propose specific wording,
and a place to put it. This is the fastest way to move this
issue forward.

Regards,    Martin.
; Fri, 29 Sep 2006 23:16:28 +0000 (UTC) Received: from mail24-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail24-cpk-R.bigfish.com (Postfix) with ESMTP id D9D35564D65 for ; Fri, 29 Sep 2006 23:16:28 +0000 (UTC) X-BigFish: VP Received: by mail24-cpk (MessageSwitch) id 1159571788840265_21471; Fri, 29 Sep 2006 23:16:28 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail24-cpk.bigfish.com (Postfix) with ESMTP id C4764564659 for ; Fri, 29 Sep 2006 23:16:28 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2006092916192730-1690604 ; Fri, 29 Sep 2006 16:19:27 -0700 In-Reply-To: <20060929213924.GG28837@ccil.org> To: ltru@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 From: Karen_Broome@spe.sony.com Message-ID: Date: Fri, 29 Sep 2006 16:15:17 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 09/29/2006 16:15:18, Serialize complete at 09/29/2006 16:15:18, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 09/29/2006 04:19:27 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 09/29/2006 04:19:28 PM, Serialize complete at 09/29/2006 04:19:28 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Ltru] Serbia and Montenegro in example X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0348758800==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0348758800== Content-Type: multipart/alternative; boundary="=_alternative 007C06C0882571F8_=" This is a multipart message in MIME format. --=_alternative 007C06C0882571F8_= Content-Type: text/plain; charset="US-ASCII" I suspect the examples section will be significantly revised during the revision of the draft, but I just wanted to note that these two private use examples likely need to be changed reflecting the recent change to ISO 3166-1: sr-Latn-QM (Serbian, Latin-script, private region) sr-Qaaa-CS (Serbian, private script, for Serbia and Montenegro) Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 --=_alternative 007C06C0882571F8_= Content-Type: text/html; charset="US-ASCII"
I suspect the examples section will be significantly revised during the revision of the draft, but I just wanted to note that these two private use examples likely need to be changed reflecting the recent change to ISO 3166-1:

sr-Latn-QM (Serbian, Latin-script, private region)
sr-Qaaa-CS (Serbian, private script, for Serbia and Montenegro)

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384
--=_alternative 007C06C0882571F8_=-- --===============0348758800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ________________________________> At 02:52 06/09/28, Karen_Broome@spe.sony.com wrote:

>I still think the text of RFC 4646 and structure leans strongly toward an assumption that all language is written. Increasingly web content features animated talking heads or video, and this content may need language tagging as well.
>
>Motion picture applications -- including television, broadcast, Digital Cinema, podcast, phonecast, multilingual electronic program guides, and local/national/university archives -- also require language tagging. The text of RFC 4646 indicates that the script can be omitted when it can be assumed. It doesn't mention that in an increasing number of cases, the assignment of a script tag is completely inappropriate.
>
>Regards,
>
>Karen Broome
>Metadata Systems Designer
>Sony Pictures Entertainment
>
>
>
>
>
>"Doug Ewell" <dewell@adelphia.net>
>
>09/27/2006 10:15 AM
>To
>"LTRU Working Group" <ltru@ietf.org>
>cc
>Subject
>[Ltru] Re: Suppress-Script batch 1
>
>
>
>
>John Cowan <cowan at ccil dot org> wrote:
>
>> Remember that the criterion for including a Suppress-Script is that
>> the script is always used for the language except in a few highly
>> restricted domains, such as writing for the blind, scholarly
>> transliteration, transcription for use in another language, and when
>> the standard script is not available.
>
>I wish we had that explanation somewhere in RFC 4646.  It's better than
>most of the explanations I've seen, certainly better than any I've
>written.
>
>--
>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
>Ltru@ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru
>
>
>_______________________________________________
>Ltru mailing list
>Ltru@ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


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


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 007BB409882571F8_=-- --===============1246198640== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1246198640==-- From ltru-bounces@ietf.org Fri Sep 29 19:16:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTRb0-0004Et-R9; Fri, 29 Sep 2006 19:16:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTRaz-0004CA-IN for ltru@ietf.org; Fri, 29 Sep 2006 19:16:41 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound2-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTRav-0006yH-Ha for ltru@ietf.org; Fri, 29 Sep 2006 19:16:41 -0400 Received: from outbound2-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-cpk-R.bigfish.com (Postfix) with ESMTP id F37147440F6 for ; Fri, 29 Sep 2006 23:16:28 +0000 (UTC) Received: from mail24-cpk-R.bigfish.com (unknown [192.168.21.3]) (using TLSv1 with cipher EDH-RSA-DES-C_______________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0348758800==-- BC3-SHA (168/168 bits)) (No client certificate requested) by outbound2-cpk.bigfish.com (Postfix) with ESMTP id ED574743F02 for ; Fri, 29 Sep 2006 23:16:28 +0000 (UTC) Received: from mail24-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail24-cpk-R.bigfish.com (Postfix) with ESMTP id D9D35564D65 for ; Fri, 29 Sep 2006 23:16:28 +0000 (UTC) X-BigFish: VP Received: by mail24-cpk (MessageSwitch) id 1159571788840265_21471; Fri, 29 Sep 2006 23:16:28 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail24-cpk.bigfish.com (Postfix) with ESMTP id C4764564659 for ; Fri, 29 Sep 2006 23:16:28 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2006092916192730-1690604 ; Fri, 29 Sep 2006 16:19:27 -0700 In-Reply-To: <20060929213924.GG28837@ccil.org> To: ltru@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 From: Karen_Broome@spe.sony.com Message-ID: Date: Fri, 29 Sep 2006 16:15:17 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 09/29/2006 16:15:18, Serialize complete at 09/29/2006 16:15:18, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 09/29/2006 04:19:27 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 09/29/2006 04:19:28 PM, Serialize complete at 09/29/2006 04:19:28 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Ltru] Serbia and Montenegro in example X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0348758800==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0348758800== Content-Type: multipart/alternative; boundary="=_alternative 007C06C0882571F8_=" This is a multipart message in MIME format. --=_alternative 007C06C0882571F8_= Content-Type: text/plain; charset="US-ASCII" I suspect the examples section will be significantly revised during the revision of the draft, but I just wanted to note that these two private use examples likely need to be changed reflecting the recent change to ISO 3166-1: sr-Latn-QM (Serbian, Latin-script, private region) sr-Qaaa-CS (Serbian, private script, for Serbia and Montenegro) Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 --=_alternative 007C06C0882571F8_= Content-Type: text/html; charset="US-ASCII"
I suspect the examples section will be significantly revised during the revision of the draft, but I just wanted to note that these two private use examples likely need to be changed reflecting the recent change to ISO 3166-1:

sr-Latn-QM (Serbian, Latin-script, private region)
sr-Qaaa-CS (Serbian, private script, for Serbia and Montenegro)

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384
--=_alternative 007C06C0882571F8_=-- --===============0348758800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0348758800==-- From ltru-bounces@ietf.org Fri Sep 29 21:02:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTTFJ-0007HO-HI; Fri, 29 Sep 2006 21:02:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTTFH-0007HC-MG for ltru@ietf.org; Fri, 29 Sep 2006 21:02:23 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTTFD-0000Bc-Nf for ltru@ietf.org; Fri, 29 Sep 2006 21:02:23 -0400 Received: by nf-out-0910.google.com with SMTP id l23so1152582nfc for ; Fri, 29 Sep 2006 18:02:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=WEwiNaIhkX7sEiOBE3aYAym8BOwjljVLLVkB+mCE1//VPe9XeRW3q1ACeAeDe1HmWvwNMmEtxuyit0iVCz1Ya1lJB+rjZ9yPLifDI3pOaz2GeE6Ccmu0H8RdknZrDbVJQlkzmIhZN85XI0gbR/DMIxkVL2tJokIqLySXRt+4MAs= Received: by 10.49.75.2 with SMTP id c2mr2456738nfl; Fri, 29 Sep 2006 18:02:18 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Fri, 29 Sep 2006 18:02:18 -0700 (PDT) Message-ID: <30b660a20609291802l359aed85wf8464c2a569ebfdf@mail.gmail.com> Date: Fri, 29 Sep 2006 18:02:18 -0700 From: "Mark Davis" To: "Karen_Broome@spe.sony.com" Subject: Re: [Ltru] Re: Suppress-Script batch 1 In-Reply-To: MIME-Version: 1.0 References: <6.0.0.20.2.20060928104743.098b7df0@localhost> X-Google-Sender-Auth: 8f5ae4fe008d6977 X-Spam-Score: 0.8 (/) X-Scan-Signature: bfef20db74c24e87b6dbcd42ea7ba67c Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1328491628==" Errors-To: ltru-bounces@ietf.org --===============1328491628== Content-Type: multipart/alternative; boundary="----=_Part_22759_14553845.1159578138461" ------=_Part_22759_14553845.1159578138461 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm mostly in agreement with the changes, but the following goes too far: 6. Script subtags MUST NOT be used to identify language that is spoken or sung. Script tags and Suppress-Script fields are not applicable to such content. Nowhere else do we say that "X cannot be used to identify Y", and with good reason. We are in the business of providing a clear mechanism for representing identifiers for languages, but we are *not* in the business of policing which content gets tagged with which tags. There are also too many edge cases. If I tagged a multimedia document with zh-Hant and the document happened to contain a snipped of spoken Chinese -- or for that matter, spoken English -- I would not be compliant to BCP 47! If you change that to the following, it would be better. Script subtags not applicable to language that that is not written in characters (for example, spoken or sung). Language tags used to identify such content should not contain script tags. Mark On 9/29/06, Karen_Broome@spe.sony.com wrote: > > > Changes to clarify use of script tags and RFC 4646bis with spoken > language: > > -Section 1- > > "In addition, knowledge about the particular language used by some > piece of information content might be useful or even required by some > types of processing; for example, spell-checking, computer- > synthesized speech, Braille transcription, or high-quality print > renderings." > > ADD after previous paragraph? > > It is important to note that the language identification needs described > above apply not only to written language, but also to spoken language such > that found in videos, audio files, songs, podcasts, films, and written > interfaces used to access or classify such content. > > -Section 2.2.3- > > Changes: > > 2. When applicable, 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. > > ADD: > > 6. Script subtags MUST NOT be used to identify language that is spoken > or sung. Script tags and Suppress-Script fields are not > applicable to such content. > > -Section 4.1- > > 2. ... > > * For example, the subtag '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 document were written in English mixing Latin > script with another script such as Braille ('Brai'), then it might be > appropriate to choose to indicate > both scripts to aid in content selection, such as the application of a > style sheet. On the other hand, the subtags 'Hant' and 'Hans' should > not be used to describe an audiovisual asset in Chinese unless the language > appears in written subtitles or captions. > > > I'm still checking to see if there are any other opportunities for > clarification. > > Regards, > > Karen Broome > Metadata Systems Designer > Sony Pictures Entertainment > 310.244.4384 > > > > > *Martin Duerst * > > 09/27/2006 06:48 PM > To > Karen_Broome@spe.sony.com, "Doug Ewell" , "LTRU > Working Group" cc > > Subject > Re: [Ltru] Re: Suppress-Script batch 1 > > > > > > > Hello Karen, > > As a technical contributor, I think you raise a very valid > point that should be documented clearly. > > As a co-chair, I'd like to ask you to propose specific wording, > and a place to put it. This is the fastest way to move this > issue forward. > > Regards, Martin. > > At 02:52 06/09/28, Karen_Broome@spe.sony.com wrote: > > >I still think the text of RFC 4646 and structure leans strongly toward an > assumption that all language is written. Increasingly web content features > animated talking heads or video, and this content may need language tagging > as well. > > > >Motion picture applications -- including television, broadcast, Digital > Cinema, podcast, phonecast, multilingual electronic program guides, and > local/national/university archives -- also require language tagging. The > text of RFC 4646 indicates that the script can be omitted when it can be > assumed. It doesn't mention that in an increasing number of cases, the > assignment of a script tag is completely inappropriate. > > > >Regards, > > > >Karen Broome > >Metadata Systems Designer > >Sony Pictures Entertainment > > > > > > > > > > > >"Doug Ewell" > > > >09/27/2006 10:15 AM > >To > >"LTRU Working Group" > >cc > >Subject > >[Ltru] Re: Suppress-Script batch 1 > > > > > > > > > >John Cowan wrote: > > > >> Remember that the criterion for including a Suppress-Script is that > >> the script is always used for the language except in a few highly > >> restricted domains, such as writing for the blind, scholarly > >> transliteration, transcription for use in another language, and when > >> the standard script is not available. > > > >I wish we had that explanation somewhere in RFC 4646. It's better than > >most of the explanations I've seen, certainly better than any I've > >written. > > > >-- > >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 > >Ltru@ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru > > > > > >_______________________________________________ > >Ltru mailing list > >Ltru@ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > ------=_Part_22759_14553845.1159578138461 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm mostly in agreement with the changes, but the following goes too far:

   6.  Script subtags MUST NOT be used to identify language that is spoken or sung. Script                   tags and Suppress-Script fields are not applicable to such content.

Nowhere else do we say that "X cannot be used to identify Y", and with good reason. We  are in the business of providing a clear mechanism for representing identifiers for languages, but we are *not* in the business of policing which content gets tagged with which tags. There are also too many edge cases. If I tagged a multimedia document with zh-Hant and the document happened to contain a snipped of spoken Chinese -- or for that matter, spoken English -- I would not be compliant to BCP 47!

If you change that to the following, it would be better.

Script subtags not applicable to language that that is not written in characters (for example, spoken or sung). Language tags used to identify such content should not contain script tags.

Mark


On 9/29/06, Karen_Broome@spe.sony.com <Karen_Broome@spe.sony.com> wrote:

Changes to clarify use of script tags and RFC 4646bis with spoken language:

-Section 1-

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

ADD after previous paragraph?

It is important to note that the language identification needs described above apply not only to written language, but also to spoken language such that found in videos, audio files, songs, podcasts, films, and written interfaces used to access or classify such content.

-Section 2.2.3-

Changes:

2.  <ADD>When applicable,</ADD> 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.

ADD:

   6.  Script subtags MUST NOT be used to identify language that is spoken or sung. Script                   tags and Suppress-Script fields are not applicable to such content.

-Section 4.1-

2.  ...

*  For example, the subtag '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 document were written in English mixing Latin script with another script such as Braille ('Brai'), then it might be appropriate to choose to indicate
both scripts to aid in content selection, such as the application of a style sheet. <ADD> On the other hand, the subtags 'Hant' and 'Hans' should not be used to describe an audiovisual asset in Chinese unless the language appears in written subtitles or captions.</ADD>

I'm still checking to see if there are any other opportunities for clarification.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
 310.244.4384




Martin Duerst <duerst@it.aoyama.ac.jp>

09/27/2006 06:48 PM

To
Karen_Broome@spe.sony.com, "Doug Ewell" <dewell@adelphia.net>, "LTRU Working Group" <ltru@ietf.org>
cc
Subject
Re: [Ltru] Re: Suppress-Script batch 1







Hello Karen,

As a technical contributor, I think you raise a very valid
point that should be documented clearly.

As a co-chair, I'd like to ask you to propose specific wording,
and a place to put it. This is the fastest way to move this
issue forward.

Regards,    Martin.

At 02:52 06/09/28, Karen_Broome@spe.sony.com wrote:

>I still think the text of RFC 4646 and structure leans strongly toward an assumption that all language is written. Increasingly web content features animated talking heads or video, and this content may need language tagging as well.
>
>Motion picture applications -- including television, broadcast, Digital Cinema, podcast, phonecast, multilingual electronic program guides, and local/national/university archives -- also require language tagging. The text of RFC 4646 indicates that the script can be omitted when it can be assumed. It doesn't mention that in an increasing number of cases, the assignment of a script tag is completely inappropriate.
>
>Regards,
>
>Karen Broome
>Metadata Systems Designer
>Sony Pictures Entertainment
>
>
>
>
>
>"Doug Ewell" <dewell@adelphia.net>
>
>09/27/2006 10:15 AM
>To
>"LTRU Working Group" <ltru@ietf.org>
>cc
>Subject
>[Ltru] Re: Suppress-Script batch 1
>
>
>
>
>John Cowan <cowan at ccil dot org> wrote:
>
>> Remember that the criterion for including a Suppress-Script is that
>> the script is always used for the language except in a few highly
>> restricted domains, such as writing for the blind, scholarly
>> transliteration, transcription for use in another language, and when
>> the standard script is not available.
>
>I wish we had that explanation somewhere in RFC 4646.  It's better than
>most of the explanations I've seen, certainly better than any I've
>written.
>
>--
>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
>Ltru@ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru
>
>
>_______________________________________________
>Ltru mailing list
>Ltru@ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


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


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru



------=_Part_22759_14553845.1159578138461-- --===============1328491628== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1328491628==-- From ltru-bounces@ietf.org Fri Sep 29 23:21:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTVPp-0005fl-4P; Fri, 29 Sep 2006 23:21:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTVPm-0005en-Ua for ltru@ietf.org; Fri, 29 Sep 2006 23:21:22 -0400 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound2-sin-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTVPf-0003rs-PG for ltru@ietf.org; Fri, 29 Sep 2006 23:21:22 -0400 Received: from outbound2-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-sin-R.bigfish.com (Postfix) with ESMTP id AE9AA14F1EF0; Sat, 30 Sep 2006 03:21:05 +0000 (UTC) Received: from mail37-sin-R.bigfish.com (unknown [10.3.252.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by outbound2-sin.bigfish.com (Postfix) with ESMTP id 958DE528058; Sat, 30 Sep 2006 03:21:05 +0000 (UTC) Received: from mail37-sin (localhost.localdomain [127.0.0.1]) by mail37-sin-R.bigfish.com (Postfix) with ESMTP id 5AEF65C89B5; Sat, 30 Sep 2006 03:21:05 +0000 (UTC) X-BigFish: VP Received: by mail37-sin (MessageSwitch) id 1159586465302388_30287; Sat, 30 Sep 2006 03:21:05 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail37-sin.bigfish.com (Postfix) with ESMTP id 44147630053; Sat, 30 Sep 2006 03:21:04 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2006092920240063-1695959 ; Fri, 29 Sep 2006 20:24:00 -0700 In-Reply-To: <30b660a20609291802l359aed85wf8464c2a569ebfdf@mail.gmail.com> To: "Mark Davis" Subject: Re: [Ltru] Re: Suppress-Script batch 1 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 From: Karen_Broome@spe.sony.com Message-ID: Date: Fri, 29 Sep 2006 20:19:49 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 09/29/2006 20:19:51, Serialize complete at 09/29/2006 20:19:51, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 09/29/2006 08:24:00 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 09/29/2006 08:24:03 PM, Serialize complete at 09/29/2006 08:24:03 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: ac00a67115ef9face560ffa0586506ca Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1334584298==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1334584298== Content-Type: multipart/alternative; boundary="=_alternative 00126067882571F9_=" This is a multipart message in MIME format. --=_alternative 00126067882571F9_= Content-Type: text/plain; charset="US-ASCII" Hmm.... I can tell you that I have had to make this a hard, fast -- if behind-the-scenes -- rule in my industry. Just in terms of feature films: When there is one application language list serving original production language as well as dubbed and subtitled versions, the dubbed content is inevitably either marked "Traditional Mandarin Chinese" or "Simplified Mandarin Chinese" -- or subtitles are classified as "Mandarin" or "Chinese," which is useless when trying to find the right version to ship to a particular region. It's bad data. I think that's how I landed in LTRU in the first place: I illustrated a need in my industry to maintain two unique language lists in applications or products that deal with both types of language. This is somewhat of a usability issue more than an identification issue, but I don't want to see a list that looks like Language: Chinese (Mandarin) Chinese (Mandarin, Simplified) Chinese (Mandarin, Traditional) That results in junk data when used by the average classifier of original, dubbed, or subtitled content because the categories are not mutually exclusive. I want to see two unique lists in a UI: Spoken Language: Chinese (Mandarin) = zh-cmn Written Language Chinese (Mandarin, Simplified) = zh-cmn-Hans Chinese (Mandarin, Traditional) = zh-cmn-Hant If we had a film that had an original language of Cantonese with subtitles in Mandarin with simplified orthography, we would identify both "zh-yue" as a spoken language (type = original) and the "zh-cmn-Hans" written language (type = subtitles). In the case you mention, we would identify all written and spoken variants in the multimedia document -- a video in a web page could have a different tag than the page itself. DVDs can feature several subtitle and dubbing options on the same disk. The distinction between written and spoken languages is common in most standards that deal with audiovisual content, and it's assumed that many works will have more than one language code assigned. Would you be any more comfortable with a "should not"? Your text to me seems to again define spoken language as the edge case -- language that is not written in characters. It's not written at all! I'd rather come straight out and acknowledge that in reality most language is spoken -- and increasingly technology allows that spoken language to be captured -- over a watered-down mention of spoken language as a "for example" in parentheses. Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 "Mark Davis" 09/29/2006 06:02 PM To "Karen_Broome@spe.sony.com" cc Doug Ewell , LTRU Working Group Subject Re: [Ltru] Re: Suppress-Script batch 1 I'm mostly in agreement with the changes, but the following goes too far: 6. Script subtags MUST NOT be used to identify language that is spoken or sung. Script tags and Suppress-Script fields are not applicable to such content. Nowhere else do we say that "X cannot be used to identify Y", and with good reason. We are in the business of providing a clear mechanism for representing identifiers for languages, but we are *not* in the business of policing which content gets tagged with which tags. There are also too many edge cases. If I tagged a multimedia document with zh-Hant and the document happened to contain a snipped of spoken Chinese -- or for that matter, spoken English -- I would not be compliant to BCP 47! If you change that to the following, it would be better. Script subtags not applicable to language that that is not written in characters (for example, spoken or sung). Language tags used to identify such content should not contain script tags. Mark On 9/29/06, Karen_Broome@spe.sony.com wrote: Changes to clarify use of script tags and RFC 4646bis with spoken language: -Section 1- "In addition, knowledge about the particular language used by some piece of information content might be useful or even required by some types of processing; for example, spell-checking, computer- synthesized speech, Braille transcription, or high-quality print renderings." ADD after previous paragraph? It is important to note that the language identification needs described above apply not only to written language, but also to spoken language such that found in videos, audio files, songs, podcasts, films, and written interfaces used to access or classify such content. -Section 2.2.3- Changes: 2. When applicable, 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. ADD: 6. Script subtags MUST NOT be used to identify language that is spoken or sung. Script tags and Suppress-Script fields are not applicable to such content. -Section 4.1- 2. ... * For example, the subtag '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 document were written in English mixing Latin script with another script such as Braille ('Brai'), then it might be appropriate to choose to indicate both scripts to aid in content selection, such as the application of a style sheet. On the other hand, the subtags 'Hant' and 'Hans' should not be used to describe an audiovisual asset in Chinese unless the language appears in written subtitles or captions. I'm still checking to see if there are any other opportunities for clarification. Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 Martin Duerst 09/27/2006 06:48 PM To Karen_Broome@spe.sony.com, "Doug Ewell" , "LTRU Working Group" cc Subject Re: [Ltru] Re: Suppress-Script batch 1 Hello Karen, As a technical contributor, I think you raise a very valid point that should be documented clearly. As a co-chair, I'd like to ask you to propose specific wording, and a place to put it. This is the fastest way to move this issue forward. Regards, Martin. At 02:52 06/09/28, Karen_Broome@spe.sony.com wrote: >I still think the text of RFC 4646 and structure leans strongly toward an assumption that all language is written. Increasingly web content features animated talking heads or video, and this content may need language tagging as well. > >Motion picture applications -- including television, broadcast, Digital Cinema, podcast, phonecast, multilingual electronic program guides, and local/national/university archives -- also require language tagging. The text of RFC 4646 indicates that the script can be omitted when it can be assumed. It doesn't mention that in an increasing number of cases, the assignment of a script tag is completely inappropriate. > >Regards, > >Karen Broome >Metadata Systems Designer >Sony Pictures Entertainment > > > > > >"Doug Ewell" > >09/27/2006 10:15 AM >To >"LTRU Working Group" >cc >Subject >[Ltru] Re: Suppress-Script batch 1 > > > > >John Cowan wrote: > >> Remember that the criterion for including a Suppress-Script is that >> the script is always used for the language except in a few highly >> restricted domains, such as writing for the blind, scholarly >> transliteration, transcription for use in another language, and when >> the standard script is not available. > >I wish we had that explanation somewhere in RFC 4646. It's better than >most of the explanations I've seen, certainly better than any I've >written. > >-- >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 >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto: duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 00126067882571F9_= Content-Type: text/html; charset="US-ASCII"
Hmm.... I can tell you that I have had to make this a hard, fast -- if behind-the-scenes -- rule in my industry.  

Just in terms of feature films: When there is one application language list serving original production language as well as dubbed and subtitled versions, the dubbed content is inevitably either marked "Traditional Mandarin Chinese" or "Simplified Mandarin Chinese"  -- or subtitles are classified as "Mandarin" or "Chinese," which is useless when trying to find the right version to ship to a particular region. It's bad data.

I think that's how I landed in LTRU in the first place: I illustrated a need in my industry to maintain two unique language lists in applications or products that deal with both types of language. This is somewhat of a usability issue more than an identification issue, but I don't want to see a list that looks like

Language:

Chinese (Mandarin)
Chinese (Mandarin, Simplified)
Chinese (Mandarin, Traditional)

That results in junk data when used by the average classifier of original, dubbed, or subtitled content because the categories are not mutually exclusive. I want to see two unique lists in a UI:

Spoken Language:

        Chinese (Mandarin) = zh-cmn

Written Language

        Chinese (Mandarin, Simplified) = zh-cmn-Hans
        Chinese (Mandarin, Traditional) = zh-cmn-Hant

If we had a film that had an original language of Cantonese with subtitles in Mandarin with simplified orthography, we would identify both "zh-yue" as a spoken language (type = original) and the "zh-cmn-Hans" written language (type = subtitles). In the case you mention, we would identify all written and spoken variants in the multimedia document -- a video in a web page could have a different tag than the page itself. DVDs can feature several subtitle and dubbing options on the same disk. The distinction between written and spoken languages is common in most standards that deal with audiovisual content, and it's assumed that many works will have more than one language code assigned.

Would you be any more comfortable with a "should not"? Your text to me seems to again define spoken language as the edge case -- language that is not written in characters. It's not written at all! I'd rather come straight out and acknowledge that in reality most language is spoken -- and increasingly technology allows that spoken language to be captured -- over a watered-down mention of spoken language as a "for example" in parentheses.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384


"Mark Davis" <mark.davis@icu-project.org>

09/29/2006 06:02 PM

To
"Karen_Broome@spe.sony.com" <Karen_Broome@spe.sony.com>
cc
Doug Ewell <dewell@adelphia.net>, LTRU Working Group <ltru@ietf.org>
Subject
Re: [Ltru] Re: Suppress-Script batch 1





I'm mostly in agreement with the changes, but the following goes too far:

  6.  Script subtags MUST NOT be used to identify language that is spoken or sung. Script                   tags and Suppress-Script fields are not applicable to such content.

Nowhere else do we say that "X cannot be used to identify Y", and with good reason. We  are in the business of providing a clear mechanism for representing identifiers for languages, but we are *not* in the business of policing which content gets tagged with which tags. There are also too many edge cases. If I tagged a multimedia document with zh-Hant and the document happened to contain a snipped of spoken Chinese -- or for that matter, spoken English -- I would not be compliant to BCP 47!

If you change that to the following, it would be better.

Script subtags not applicable to language that that is not written in characters (for example, spoken or sung). Language tags used to identify such content should not contain script tags.

Mark
On 9/29/06, Karen_Broome@spe.sony.com <Karen_Broome@spe.sony.com> wrote:

Changes to clarify use of script tags and RFC 4646bis with spoken language:

-Section 1-

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

ADD after previous paragraph?

It is important to note that the language identification needs described above apply not only to written language, but also to spoken language such that found in videos, audio files, songs, podcasts, films, and written interfaces used to access or classify such content.

-Section 2.2.3-

Changes:

2.  <ADD>When applicable,</ADD> 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.

ADD:

  6.  Script subtags MUST NOT be used to identify language that is spoken or sung. Script                   tags and Suppress-Script fields are not applicable to such content.

-Section 4.1-

2.  ...

*  For example, the subtag '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 document were written in English mixing Latin script with another script such as Braille ('Brai'), then it might be appropriate to choose to indicate
both scripts to aid in content selection, such as the application of a style sheet. <ADD> On the other hand, the subtags 'Hant' and 'Hans' should not be used to describe an audiovisual asset in Chinese unless the language appears in written subtitles or captions.</ADD>


I'm still checking to see if there are any other opportunities for clarification.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384



Martin Duerst <duerst@it.aoyama.ac.jp>

09/27/2006 06:48 PM


To
Karen_Broome@spe.sony.com, "Doug Ewell" <dewell@adelphia.net>, "LTRU Working Group" <ltru@ietf.org>
cc
Subject
Re: [Ltru] Re: Suppress-Script batch 1







Hello Karen,

As a technical contributor, I think you raise a very valid
point that should be documented clearly.

As a co-chair, I'd like to ask you to propose specific wording,
and a place to put it. This is the fastest way to move this
issue forward.

Regards,    Martin.

At 02:52 06/09/28, Karen_Broome@spe.sony.com wrote:

>I still think the text of RFC 4646 and structure leans strongly toward an assumption that all language is written. Increasingly web content features animated talking heads or video, and this content may need language tagging as well.
>
>Motion picture applications -- including television, broadcast, Digital Cinema, podcast, phonecast, multilingual electronic program guides, and local/national/university archives -- also require language tagging. The text of RFC 4646 indicates that the script can be omitted when it can be assumed. It doesn't mention that in an increasing number of cases, the assignment of a script tag is completely inappropriate.
>
>Regards,
>
>Karen Broome
>Metadata Systems Designer
>Sony Pictures Entertainment
>
>
>
>
>
>"Doug Ewell" <dewell@adelphia.net>
>
>09/27/2006 10:15 AM
>To
>"LTRU Working Group" <ltru@ietf.org>
>cc
>Subject
>[Ltru] Re: Suppress-Script batch 1
>
>
>
>
>John Cowan <cowan at ccil dot org> wrote:
>
>> Remember that the criterion for including a Suppress-Script is that
>> the script is always used for the language except in a few highly
>> restricted domains, such as writing for the blind, scholarly
>> transliteration, transcription for use in another language, and when
>> the standard script is not available.
>
>I wish we had that explanation somewhere in RFC 4646.  It's better than
>most of the explanations I've seen, certainly better than any I've
>written.
>
>--
>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
>Ltru@ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru
>
>
>_______________________________________________
>Ltru mailing list
>Ltru@ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


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


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 00126067882571F9_=-- --===============1334584298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1334584298==-- From ltru-bounces@ietf.org Sat Sep 30 01:17:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTXEA-0002J8-6m; Sat, 30 Sep 2006 01:17:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTXE9-0002J3-3m for ltru@ietf.org; Sat, 30 Sep 2006 01:17:29 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTXE6-0002JC-P3 for ltru@ietf.org; Sat, 30 Sep 2006 01:17:29 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060930051726.GSCL437.mta13.adelphia.net@DGBP7M81> for ; Sat, 30 Sep 2006 01:17:26 -0400 Message-ID: <004101c6e44f$b72df6f0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 29 Sep 2006 22:17:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Ltru] Re: Re-use of a region code for the same purpose X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Misha Wolf wrote: > Let's consider some case other than "CS". If Switzerland > split into two countries, and five years later the two > re-united, is there any reason why ISO and we should not > use the original "CH"? I'm trying to think of actual cases like this, where a country ceased to exist (whether by splitting up or by being absorbed into another) and then came back into existence. One fairly recent set of examples would be the Baltic states, Estonia, Latvia, and Lithuania, which lost their independence in 1940 and regained it in 1991. If ISO 3166-1 had existed in 1940, and EE and LV and LT had been withdrawn when the Soviet Union annexed the Baltic states, it might be reasonable to expect that there would be support 51 years later for re-assigning the same code elements, rather than inventing new ones. In 1958 Syria and Egypt joined to form the United Arab Republic. Syria left in 1961 and Egypt continued using the name until 1971. If ISO 3166-1 had existed at the time, would it have used the same code elements for the "old" and "new" Syria, and for the "old" and "new" Egypt? I think we would have to be guided by ISO 3166/MA and UNSD on this. -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 02:08:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTY1e-0000dd-2c; Sat, 30 Sep 2006 02:08:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTY1d-0000dX-1i for ltru@ietf.org; Sat, 30 Sep 2006 02:08:37 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTY1X-000786-MN for ltru@ietf.org; Sat, 30 Sep 2006 02:08:37 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060930060831.BHSL360.mta11.adelphia.net@DGBP7M81>; Sat, 30 Sep 2006 02:08:31 -0400 Message-ID: <004f01c6e456$da197660$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <00f901c6e399$643dc8f0$6401a8c0@DGBP7M81> <20060929193738.GD28837@ccil.org> Subject: Re: [Ltru] Submission: draft-ietf-ltru-4645bis-00 Date: Fri, 29 Sep 2006 23:08:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >> o If the language was included within a macrolanguage, an extended > > "encompassed by a macrolanguage" is the style used by 639-3. Also less clumsy. +1 >> Because it does not represent a useful linguistic distinction for >> tagging purposes, it was deprecated without a Preferred-Value. > > Better to be less forthright: "Because it is not believed to > represent". +1. I also prefer "entity" over "distinction" in this sentence; any objections? >> This document specifies the complete updated contents to be used by >> IANA in populating the Language Subtag Registry. > > "a complete replacement of the contents of the LSR to be used by IANA > in updating it" makes it clear that this isn't just a complete (as > opposed to partial) *update*, it *replaces* what came before. +1. This refers to Section 4. I think "document" should be changed to "memo" for consistency; I'll check for other self-referential uses of "document" (which I have a habit of overusing). >> In its initial phase as an Internet-Draft, this memo contained the >> complete updated contents of the Language Subtag Registry. As an > > Same story. +1. This is Section 5. What about the third paragraph of Section 1; does that need retooling too? >> RFC, it contains a pointer to the updated content for the Registry, > > Just "pointer to the Registry". Good. Should we also specify the exact URL, since that is now known (which was not the case during LTRU 1.0)? I know some folks don't like explicit URLs, but we already direct readers to http://www.iana.org/numbers.html, which is no better. > I may have more comments later. Bring 'em. This is the group's draft, to be shaped and molded by the group; that's why I insist on "Editor." -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 02:18:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTYAq-0005DE-12; Sat, 30 Sep 2006 02:18:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTYAp-00057y-2N for ltru@ietf.org; Sat, 30 Sep 2006 02:18:07 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTYAm-0007kY-Is for ltru@ietf.org; Sat, 30 Sep 2006 02:18:07 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060930061803.BKNP360.mta11.adelphia.net@DGBP7M81>; Sat, 30 Sep 2006 02:18:03 -0400 Message-ID: <005201c6e458$2f9d97f0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "Mark Davis" , References: <6.0.0.20.2.20060928104743.098b7df0@localhost> <30b660a20609291802l359aed85wf8464c2a569ebfdf@mail.gmail.com> Subject: Re: [Ltru] Re: Suppress-Script batch 1 Date: Fri, 29 Sep 2006 23:18:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I suppose if we had multimedia content, like a children's song being sung with the lyrics subtitled (possibly with a bouncing ball), then a written component would be involved and script might be relevant. I agree that we should not make it look as though written content is the norm and non-written content is some kind of weird fringe exception. We should be able to have all our existing statements about script subtag usage, and also state that they are inappropriate for non-written content. In particular, Karen's proposed addition of "When applicable" to Section 2.2.3 is subtle but gets the point across. -- 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 ----- Original Message ----- From: Mark Davis To: Karen_Broome@spe.sony.com Cc: Martin Duerst ; Doug Ewell ; LTRU Working Group Sent: Friday, September 29, 2006 18:02 Subject: Re: [Ltru] Re: Suppress-Script batch 1 I'm mostly in agreement with the changes, but the following goes too far: 6. Script subtags MUST NOT be used to identify language that is spoken or sung. Script tags and Suppress-Script fields are not applicable to such content. Nowhere else do we say that "X cannot be used to identify Y", and with good reason. We are in the business of providing a clear mechanism for representing identifiers for languages, but we are *not* in the business of policing which content gets tagged with which tags. There are also too many edge cases. If I tagged a multimedia document with zh-Hant and the document happened to contain a snipped of spoken Chinese -- or for that matter, spoken English -- I would not be compliant to BCP 47! If you change that to the following, it would be better. Script subtags not applicable to language that that is not written in characters (for example, spoken or sung). Language tags used to identify such content should not contain script tags. Mark On 9/29/06, Karen_Broome@spe.sony.com wrote: Changes to clarify use of script tags and RFC 4646bis with spoken language: -Section 1- "In addition, knowledge about the particular language used by some piece of information content might be useful or even required by some types of processing; for example, spell-checking, computer- synthesized speech, Braille transcription, or high-quality print renderings." ADD after previous paragraph? It is important to note that the language identification needs described above apply not only to written language, but also to spoken language such that found in videos, audio files, songs, podcasts, films, and written interfaces used to access or classify such content. -Section 2.2.3- Changes: 2. When applicable, 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. ADD: 6. Script subtags MUST NOT be used to identify language that is spoken or sung. Script tags and Suppress-Script fields are not applicable to such content. -Section 4.1- 2. ... * For example, the subtag '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 document were written in English mixing Latin script with another script such as Braille ('Brai'), then it might be appropriate to choose to indicate both scripts to aid in content selection, such as the application of a style sheet. On the other hand, the subtags 'Hant' and 'Hans' should not be used to describe an audiovisual asset in Chinese unless the language appears in written subtitles or captions. I'm still checking to see if there are any other opportunities for clarification. Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 Martin Duerst 09/27/2006 06:48 PM ToKaren_Broome@spe.sony.com, "Doug Ewell" , "LTRU Working Group" cc SubjectRe: [Ltru] Re: Suppress-Script batch 1 Hello Karen, As a technical contributor, I think you raise a very valid point that should be documented clearly. As a co-chair, I'd like to ask you to propose specific wording, and a place to put it. This is the fastest way to move this issue forward. Regards, Martin. At 02:52 06/09/28, Karen_Broome@spe.sony.com wrote: >I still think the text of RFC 4646 and structure leans strongly toward >an assumption that all language is written. Increasingly web content >features animated talking heads or video, and this content may need >language tagging as well. > >Motion picture applications -- including television, broadcast, Digital >Cinema, podcast, phonecast, multilingual electronic program guides, and >local/national/university archives -- also require language tagging. >The text of RFC 4646 indicates that the script can be omitted when it >can be assumed. It doesn't mention that in an increasing number of >cases, the assignment of a script tag is completely inappropriate. > >Regards, > >Karen Broome >Metadata Systems Designer >Sony Pictures Entertainment > > > > > >"Doug Ewell" > >09/27/2006 10:15 AM >To >"LTRU Working Group" >cc >Subject >[Ltru] Re: Suppress-Script batch 1 > > > > >John Cowan wrote: > >> Remember that the criterion for including a Suppress-Script is that >> the script is always used for the language except in a few highly >> restricted domains, such as writing for the blind, scholarly >> transliteration, transcription for use in another language, and when >> the standard script is not available. > >I wish we had that explanation somewhere in RFC 4646. It's better than >most of the explanations I've seen, certainly better than any I've >written. > >-- >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 >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto: duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 04:18:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTa2u-0000Tq-0P; Sat, 30 Sep 2006 04:18:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTa2s-0000Sx-7G for ltru@ietf.org; Sat, 30 Sep 2006 04:18:02 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTZmg-0003X8-CL for ltru@ietf.org; Sat, 30 Sep 2006 04:01:24 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8U817S7005058 for ; Sat, 30 Sep 2006 17:01:07 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 043d_d3f387b6_5059_11db_86ad_0014221fa3c9; Sat, 30 Sep 2006 17:01:07 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:37319) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 30 Sep 2006 17:01:02 +0900 Message-Id: <6.0.0.20.2.20060930163552.09962ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 30 Sep 2006 16:41:18 +0900 To: "Mark Davis" , "Karen_Broome@spe.sony.com" From: Martin Duerst Subject: Re: [Ltru] Re: Suppress-Script batch 1 In-Reply-To: <30b660a20609291802l359aed85wf8464c2a569ebfdf@mail.gmail.co m> References: <6.0.0.20.2.20060928104743.098b7df0@localhost> <30b660a20609291802l359aed85wf8464c2a569ebfdf@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Just a very small editorial fix, otherwise +1: At 10:02 06/09/30, Mark Davis wrote: >I'm mostly in agreement with the changes, but the following goes too far: > > 6. Script subtags MUST NOT be used to identify language that is spoken or sung. Script tags and Suppress-Script fields are not applicable to such content. >If you change that to the following, it would be better. > >Script subtags not applicable to language that that is not written in characters (for example, spoken or sung). Language tags used to identify such content should not contain script tags. Please change: Script subtags not applicable to language that that is not written in characters (for example, spoken or sung). to: Script subtags are not applicable to language that that is not written in characters (for example, spoken or sung). Maybe even better: Script subtags are not applicable, and therefore preferably are left out, for content that does not use any script, for example because it is spoken or sung. This does two things: - Says explicitly that if a script tag isn't applicable, don't use it in the tag. - Makes the text somewhat more independent of the description of 'script'. (As an example, if ever we would get into the situation that sign language is recognized as a 'script', but there are not characters for it.) Not a main point, but just to be on the safe side. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 04:18:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTa2t-0000Ti-R4; Sat, 30 Sep 2006 04:18:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTa2s-0000Sx-4b for ltru@ietf.org; Sat, 30 Sep 2006 04:18:02 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTZmg-0003Xh-CK for ltru@ietf.org; Sat, 30 Sep 2006 04:01:25 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8U81AON005070 for ; Sat, 30 Sep 2006 17:01:10 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 0426_d5813786_5059_11db_9ab2_0014221fa3c9; Sat, 30 Sep 2006 17:01:09 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:37319) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 30 Sep 2006 17:01:05 +0900 Message-Id: <6.0.0.20.2.20060930164637.09942840@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 30 Sep 2006 16:50:04 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Submission: draft-ietf-ltru-4645bis-00 In-Reply-To: <004f01c6e456$da197660$6401a8c0@DGBP7M81> References: <00f901c6e399$643dc8f0$6401a8c0@DGBP7M81> <20060929193738.GD28837@ccil.org> <004f01c6e456$da197660$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 15:08 06/09/30, Doug Ewell wrote: >John Cowan wrote: >>> This document specifies the complete updated contents to be used by IANA in populating the Language Subtag Registry. >> >> "a complete replacement of the contents of the LSR to be used by IANA in updating it" makes it clear that this isn't just a complete (as opposed to partial) *update*, it *replaces* what came before. > >+1. This refers to Section 4. I think "document" should be changed to "memo" for consistency; I'll check for other self-referential uses of "document" (which I have a habit of overusing). One point I'm wondering are registrations accepted on ietf-languages between the final internet draft and the point in time when IANA does the update. How was this handled last time? Do we have some language in one of the drafts? I just remember the gr-Latn case, which led to quite a bit of private exchanges. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 04:18:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTa2t-0000Tm-UZ; Sat, 30 Sep 2006 04:18:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTa2s-0000Sx-5N for ltru@ietf.org; Sat, 30 Sep 2006 04:18:02 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTZmg-0003Xf-CL for ltru@ietf.org; Sat, 30 Sep 2006 04:01:25 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8U8197r005066 for ; Sat, 30 Sep 2006 17:01:09 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5bff_d5192b3c_5059_11db_9809_0014221f2a2d; Sat, 30 Sep 2006 17:01:08 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:37319) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 30 Sep 2006 17:01:04 +0900 Message-Id: <6.0.0.20.2.20060930164243.09942c00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 30 Sep 2006 16:43:52 +0900 To: Karen_Broome@spe.sony.com From: Martin Duerst Subject: Re: [Ltru] Re: Suppress-Script batch 1 In-Reply-To: References: <6.0.0.20.2.20060928104743.098b7df0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org In general +1, except for Mark's correction and a small editorial correction below. At 08:15 06/09/30, Karen_Broome@spe.sony.com wrote: >ADD after previous paragraph? > >It is important to note that the language identification needs described above apply not only to written language, but also to spoken language such that found in videos, audio files, songs, podcasts, films, and written interfaces used to access or classify such content. Please change "such that found" to "such as found". Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 04:18:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTa2t-0000Ti-R4; Sat, 30 Sep 2006 04:18:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTa2s-0000Sx-4b for ltru@ietf.org; Sat, 30 Sep 2006 04:18:02 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTZmg-0003Xh-CK for ltru@ietf.org; Sat, 30 Sep 2006 04:01:25 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8U81AON005070 for ; Sat, 30 Sep 2006 17:01:10 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 0426_d5813786_5059_11db_9ab2_0014221fa3c9; Sat, 30 Sep 2006 17:01:09 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:37319) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 30 Sep 2006 17:01:05 +0900 Message-Id: <6.0.0.20.2.20060930164637.09942840@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 30 Sep 2006 16:50:04 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Submission: draft-ietf-ltru-4645bis-00 In-Reply-To: <004f01c6e456$da197660$6401a8c0@DGBP7M81> References: <00f901c6e399$643dc8f0$6401a8c0@DGBP7M81> <20060929193738.GD28837@ccil.org> <004f01c6e456$da197660$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 15:08 06/09/30, Doug Ewell wrote: >John Cowan wrote: >>> This document specifies the complete updated contents to be used by IANA in populating the Language Subtag Registry. >> >> "a complete replacement of the contents of the LSR to be used by IANA in updating it" makes it clear that this isn't just a complete (as opposed to partial) *update*, it *replaces* what came before. > >+1. This refers to Section 4. I think "document" should be changed to "memo" for consistency; I'll check for other self-referential uses of "document" (which I have a habit of overusing). One point I'm wondering are registrations accepted on ietf-languages between the final internet draft and the point in time when IANA does the update. How was this handled last time? Do we have some language in one of the drafts? I just remember the gr-Latn case, which led to quite a bit of private exchanges. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 04:18:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTa2t-0000Tm-UZ; Sat, 30 Sep 2006 04:18:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTa2s-0000Sx-5N for ltru@ietf.org; Sat, 30 Sep 2006 04:18:02 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTZmg-0003Xf-CL for ltru@ietf.org; Sat, 30 Sep 2006 04:01:25 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8U8197r005066 for ; Sat, 30 Sep 2006 17:01:09 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5bff_d5192b3c_5059_11db_9809_0014221f2a2d; Sat, 30 Sep 2006 17:01:08 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:37319) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 30 Sep 2006 17:01:04 +0900 Message-Id: <6.0.0.20.2.20060930164243.09942c00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 30 Sep 2006 16:43:52 +0900 To: Karen_Broome@spe.sony.com From: Martin Duerst Subject: Re: [Ltru] Re: Suppress-Script batch 1 In-Reply-To: References: <6.0.0.20.2.20060928104743.098b7df0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org In general +1, except for Mark's correction and a small editorial correction below. At 08:15 06/09/30, Karen_Broome@spe.sony.com wrote: >ADD after previous paragraph? > >It is important to note that the language identification needs described above apply not only to written language, but also to spoken language such that found in videos, audio files, songs, podcasts, films, and written interfaces used to access or classify such content. Please change "such that found" to "such as found". Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 05:06:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTanR-0007aO-RF; Sat, 30 Sep 2006 05:06:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTanP-0007ZK-Sv for ltru@ietf.org; Sat, 30 Sep 2006 05:06:08 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTanL-0004Xg-1q for ltru@ietf.org; Sat, 30 Sep 2006 05:06:07 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k8U961nD010490 for ; Sat, 30 Sep 2006 18:06:01 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5cd2_e4ae3d04_5062_11db_9510_0014221f2a2d; Sat, 30 Sep 2006 18:06:01 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:45083) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 30 Sep 2006 18:05:56 +0900 Message-Id: <6.0.0.20.2.20060930175917.0a67aec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 30 Sep 2006 18:00:34 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Registry deltas In-Reply-To: <012f01c6e3cb$fbd25690$6401a8c0@DGBP7M81> References: <012f01c6e3cb$fbd25690$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org For me, definitely yes. Also useful would be deltas for future drafts, for all of the data itself, in a suitable form. Regards, Martin. At 22:34 06/09/29, Doug Ewell wrote: >Would it be useful to the group, for evaluation purposes, if I produced a diff file containing the changes between the existing Registry and the one proposed in draft-4645bis-00? This would exclude the 7,200 added subtags and include only the other changes, such as Descriptions and Comments added, grandfathered tags changed to redundant, and such. I know I've relied on such deltas while working on it. > >-- >Doug Ewell >Fullerton, California, USA >http://users.adelphia.net/~dewell/ >RFC 4645 * UTN #14 > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 08:12:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTdhU-00066W-FN; Sat, 30 Sep 2006 08:12:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTdhT-000669-0c for ltru@lists.ietf.org; Sat, 30 Sep 2006 08:12:11 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTdhP-0004Q7-Jf for ltru@lists.ietf.org; Sat, 30 Sep 2006 08:12:10 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GTdgz-0007An-9d for ltru@lists.ietf.org; Sat, 30 Sep 2006 14:11:41 +0200 Received: from pd9fba948.dip0.t-ipconnect.de ([217.251.169.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Sep 2006 14:11:41 +0200 Received: from nobody by pd9fba948.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Sep 2006 14:11:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 30 Sep 2006 14:10:38 +0200 Organization: Lines: 22 Message-ID: <451E5EBE.3DE@xyzzy.claranet.de> References: <6.0.0.20.2.20060928104743.098b7df0@localhost> <30b660a20609291802l359aed85wf8464c2a569ebfdf@mail.gmail.com> <30b660a20609291802l359aed85wf8464c2a569ebfdf@mail.gmail.co m> <6.0.0.20.2.20060930163552.09962ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba948.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] Re: Suppress-Script batch 1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > Maybe even better: > Script subtags are not applicable, and therefore > preferably are left out, for content that does not > use any script, for example because it is > spoken or sung. > This does two things: > - Says explicitly that if a script tag isn't applicable, > don't use it in the tag. > - Makes the text somewhat more independent of the description > of 'script'. (As an example, if ever we would get into the > situation that sign language is recognized as a 'script', > but there are not characters for it.) The "preferably are" is a near miss wrt How about s/preferably are/SHOULD be/ ? Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 08:24:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTdtQ-0003GZ-WB; Sat, 30 Sep 2006 08:24:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTdtP-0003GJ-N6 for ltru@lists.ietf.org; Sat, 30 Sep 2006 08:24:31 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTdtO-0006AO-E7 for ltru@lists.ietf.org; Sat, 30 Sep 2006 08:24:31 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GTdtD-00011i-2T for ltru@lists.ietf.org; Sat, 30 Sep 2006 14:24:19 +0200 Received: from pd9fba948.dip0.t-ipconnect.de ([217.251.169.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Sep 2006 14:24:19 +0200 Received: from nobody by pd9fba948.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Sep 2006 14:24:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 30 Sep 2006 14:23:56 +0200 Organization: Lines: 12 Message-ID: <451E61DC.784A@xyzzy.claranet.de> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <451ACCC5.6010609@yahoo-inc.com> <20060929213924.GG28837@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba948.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: Suppress-script considered least harmful X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > I'm happy to keep Suppress-Script confined (as a matter of > administrative policy, not RFC 4646bis rule) to the languages > of 639-1 and 639-2. The registry won't tell users what's what, so I'm not happy with your proposal. If this boils down to "let's try hard to get it right at least for 639-1 and 639-2" it's okay. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 08:34:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTe3N-0007Ll-1P; Sat, 30 Sep 2006 08:34:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTe3L-0007Lf-5a for ltru@lists.ietf.org; Sat, 30 Sep 2006 08:34:47 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTe3J-0000DG-SF for ltru@lists.ietf.org; Sat, 30 Sep 2006 08:34:47 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GTe3I-000323-CR for ltru@lists.ietf.org; Sat, 30 Sep 2006 14:34:44 +0200 Received: from pd9fba948.dip0.t-ipconnect.de ([217.251.169.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Sep 2006 14:34:44 +0200 Received: from nobody by pd9fba948.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Sep 2006 14:34:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 30 Sep 2006 14:32:57 +0200 Organization: Lines: 19 Message-ID: <451E63F9.2CA8@xyzzy.claranet.de> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> <6.0.0.20.2.20060928193237.08122670__32691.3689300001$1159440247$gmane$org@localhost> <451C66A3.52C9@xyzzy.claranet.de> <30b660a20609281824m560066c0k1202af61d673e724@mail.gmail.com> <451C899C.3C0E@xyzzy.claranet.de> <30b660a20609290740nc2c3f8bp7985c80202a7d7f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba948.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: Korean (and Japanese) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: >> "And the same new applications need a licence to >> suppress Jpan in ja-Jpan for backwards compatibility, they >> need your proposed Suppress-Script." > This is untrue. I need no licence to tag anything as simply > 'ja' (instead of ja-), if that's all I want to > tag it with. You're a human user, not a "new application". It's the job of the application to accept ja-Latn if you say so, and it could ask "are you sure" if you say "ja-Jpan". Without a "licence" in the form of a Suppress-Script the application would accept ja-Latn exactly like ja-Jpan. Getting no match for any legacy ja-JP bogeys. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 08:49:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTeHV-0005un-AW; Sat, 30 Sep 2006 08:49:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTeHU-0005uf-JF for ltru@lists.ietf.org; Sat, 30 Sep 2006 08:49:24 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTeHT-0001dl-9y for ltru@lists.ietf.org; Sat, 30 Sep 2006 08:49:24 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GTeHK-00062r-3A for ltru@lists.ietf.org; Sat, 30 Sep 2006 14:49:14 +0200 Received: from pd9fba948.dip0.t-ipconnect.de ([217.251.169.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Sep 2006 14:49:14 +0200 Received: from nobody by pd9fba948.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Sep 2006 14:49:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 30 Sep 2006 14:48:22 +0200 Organization: Lines: 28 Message-ID: <451E6796.4686@xyzzy.claranet.de> References: <20060929213924.GG28837@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba948.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Ltru] Re: Serbia and Montenegro in example X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Karen_Broome@spe.sony.com wrote: > I just wanted to note that these two private use examples > likely need to be changed reflecting the recent change to > ISO 3166-1: > sr-Latn-QM (Serbian, Latin-script, private region) Could be Kosovo or similar, I think that's still okay. > sr-Qaaa-CS Yes, that has to be fixed. In theory I could reactivate my meta wikimedia account (if I recall the password) and ask them if we can use their server to "note" pending 464xbis issues, after all meta is their I18N central as far as it doesn't concern code. In practice I hope somebody here has a more straight forward idea, what about say the CVS servers for ICU or CLDR ? For subversion there is even an optional module "Trac" with a tracker and built-in Wiki. The IESG uses "Trac", maybe they'd be willing to let us test it. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 11:44:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTh0m-0005Ds-CB; Sat, 30 Sep 2006 11:44:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTh0l-0005B4-Ca for ltru@ietf.org; Sat, 30 Sep 2006 11:44:19 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTh0j-0004l9-1a for ltru@ietf.org; Sat, 30 Sep 2006 11:44:19 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060930154412.QLIO437.mta13.adelphia.net@DGBP7M81> for ; Sat, 30 Sep 2006 11:44:12 -0400 Message-ID: <006501c6e4a7$46774210$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <6.0.0.20.2.20060928104743.098b7df0@localhost> <30b660a20609291802l359aed85wf8464c2a569ebfdf@mail.gmail.com> <6.0.0.20.2.20060930163552.09962ec0@localhost> Subject: Re: [Ltru] Re: Suppress-Script batch 1 Date: Sat, 30 Sep 2006 08:44:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > Please change: > Script subtags not applicable to language that that is not written > in characters (for example, spoken or sung). > to: > Script subtags are not applicable to language that that is not > written in characters (for example, spoken or sung). At the very least, remove "that that". -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 11:59:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GThFd-0002kq-GQ; Sat, 30 Sep 2006 11:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GThFb-0002kB-FL for ltru@ietf.org; Sat, 30 Sep 2006 11:59:39 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GThFa-0006QG-52 for ltru@ietf.org; Sat, 30 Sep 2006 11:59:39 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060930155937.QXZC437.mta13.adelphia.net@DGBP7M81>; Sat, 30 Sep 2006 11:59:37 -0400 Message-ID: <006701c6e4a9$6e3a5380$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <00f901c6e399$643dc8f0$6401a8c0@DGBP7M81> <20060929193738.GD28837@ccil.org> <004f01c6e456$da197660$6401a8c0@DGBP7M81> <6.0.0.20.2.20060930164637.09942840@localhost> Subject: Re: [Ltru] Submission: draft-ietf-ltru-4645bis-00 Date: Sat, 30 Sep 2006 08:59:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > One point I'm wondering are registrations accepted on ietf-languages > between the final internet draft and the point in time when IANA does > the update. > > How was this handled last time? Do we have some language in one of the > drafts? I just remember the gr-Latn case, which led to quite a bit of > private exchanges. Yeah. I labored over that wording somewhat. We really don't have a great plan in the event of delay, and last time there was significant delay. This was partly brought on by the fact that we had a third deliverable (4647) that held up the first two for many months. I'm hoping that will not be an issue this time. Also noticeable, though not terribly important, is the date 2005-10-16 on most of the Added dates in the Registry. That was the date of the final I-D, but it's pretty meaningless now, and in particular it has little to do with when the draft was approved (November 2005), or when it became an RFC (three weeks ago). It would be nice if that date could be kept somewhere close to reality for the new subtags. (Note the semi-random date 2007-01-01 all over the draft-4645bis-00 Registry.) Ideally such changes would be kept to a minimum during that critical period, and the I-D process would move along from IESG Last Call to RFC publication at a reasonable pace. I realize both are somewhat wishful thinking. -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 12:30:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GThin-0008BY-AG; Sat, 30 Sep 2006 12:29:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GThim-00084c-2j for ltru@lists.ietf.org; Sat, 30 Sep 2006 12:29:48 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GThik-00072V-O7 for ltru@lists.ietf.org; Sat, 30 Sep 2006 12:29:48 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GThiQ-0006ew-Jx for ltru@lists.ietf.org; Sat, 30 Sep 2006 18:29:29 +0200 Received: from du-001-068.access.de.clara.net ([212.82.227.68]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Sep 2006 18:29:26 +0200 Received: from nobody by du-001-068.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Sep 2006 18:29:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 30 Sep 2006 18:28:46 +0200 Organization: Lines: 25 Message-ID: <451E9B3E.4CC@xyzzy.claranet.de> References: <00f901c6e399$643dc8f0$6401a8c0@DGBP7M81> <20060929193738.GD28837@ccil.org> <004f01c6e456$da197660$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-068.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Ltru] Re: Submission: draft-ietf-ltru-4645bis-00 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Should we also specify the exact URL, since that is > now known (which was not the case during LTRU 1.0)? I don't trust that this works, their Webmaster might be forced to reorganize this as part of their general reorganization, and might forget to redirect the old URL. And the IETF apparently has no PURLs, so that's also out - the issue is to get maintainers for PURLs, not some random individual who might run or die. > I know some folks don't like explicit URLs The RFC-editor among others, broken URLs in published RFCs are a PITA. > http://www.iana.org/numbers.html, which is no better. I hope that IANA won't screw-up this link as long as it exists. A backup mirror would be nice, if say ISO offers to host it. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 12:52:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTi4k-0000l1-Az; Sat, 30 Sep 2006 12:52:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTi4i-0000kj-Vo for ltru@lists.ietf.org; Sat, 30 Sep 2006 12:52:28 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTi4h-0006wH-Ms for ltru@lists.ietf.org; Sat, 30 Sep 2006 12:52:28 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GTi4Q-0003H5-0R for ltru@lists.ietf.org; Sat, 30 Sep 2006 18:52:10 +0200 Received: from du-001-068.access.de.clara.net ([212.82.227.68]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Sep 2006 18:52:10 +0200 Received: from nobody by du-001-068.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Sep 2006 18:52:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 30 Sep 2006 18:51:18 +0200 Organization: Lines: 12 Message-ID: <451EA086.7E6A@xyzzy.claranet.de> References: <004101c6e44f$b72df6f0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-068.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: Re-use of a region code for the same purpose X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > we would have to be guided by ISO 3166/MA and UNSD on this. We only need a statement that a deprecated subtag can be revived for its former purpose by the relevant ISO standard, and that the "deprecated" field in the registry should then be removed - instead of registering UN numbers where this is not not strictly necessary to avoid conflicts. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 14:13:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTjKk-0006ip-PG; Sat, 30 Sep 2006 14:13:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTjKj-0006ik-OL for ltru@lists.ietf.org; Sat, 30 Sep 2006 14:13:05 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTjKj-0003r8-5h for ltru@lists.ietf.org; Sat, 30 Sep 2006 14:13:05 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1307907nfc for ; Sat, 30 Sep 2006 11:13:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=TcFQcY1V6OrTDj8AhvD2dPjTwEoj4NvTtizG1BX9f7xOX0JjFlK5JiqxJDfi/Z7ehZjf2eaf0dCjn4wrr35h8JpPJtmJ+ehdSd6GK3lxzPNpWaXJSzXLec+zlbEeo2I5Xpb/5tBHhnOT4fE6d0Ns5nG8YlO/OZ0GMeesijP0ntg= Received: by 10.48.210.20 with SMTP id i20mr6932724nfg; Sat, 30 Sep 2006 11:13:03 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Sat, 30 Sep 2006 11:13:03 -0700 (PDT) Message-ID: <30b660a20609301113t7330ca8cqc848d4ddbb758a10@mail.gmail.com> Date: Sat, 30 Sep 2006 11:13:03 -0700 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: Korean (and Japanese) In-Reply-To: <451E63F9.2CA8@xyzzy.claranet.de> MIME-Version: 1.0 References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> <6.0.0.20.2.20060928193237.08122670__32691.3689300001$1159440247$gmane$org@localhost> <451C66A3.52C9@xyzzy.claranet.de> <30b660a20609281824m560066c0k1202af61d673e724@mail.gmail.com> <451C899C.3C0E@xyzzy.claranet.de> <30b660a20609290740nc2c3f8bp7985c80202a7d7f@mail.gmail.com> <451E63F9.2CA8@xyzzy.claranet.de> X-Google-Sender-Auth: c6901cc19818772d X-Spam-Score: 0.3 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1220157663==" Errors-To: ltru-bounces@ietf.org --===============1220157663== Content-Type: multipart/alternative; boundary="----=_Part_30789_15705624.1159639983706" ------=_Part_30789_15705624.1159639983706 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't know what kind of scenario you have in mind, but for most I'm familiar with, having suppress-script in the registry is of very little aid in the UI. Let's suppose I'm picking the language in my browser. Typically I'll get a pull-down list with the most common languages. So that's already pre-canned, and -- notably -- takes some intelligence to produce. Nobody can take arbitrary combinations of language, script, and region subtags, since that would produce a huge, unusable list. Instead, someone needs to take the time to figure out which ones are worth separating out for presentation to the user. That involves *far* more than suppress-script: you need to know, for example, which region-based variations are important to separate out. Then, if you are lucky the UI will give you a way to select additional choices (Firefox, for example, does even let you do this). A good UI will not just have the user type in some random string and validate -- it will provide pull-down menus that help to guide the user to picking reasonable choices. (Even the choice of language subtag alone gets will get complicated with 639-3. Probably needs some fairly careful thought to allow people to get to the one they want without too much hassle.) With the UI selection for script, one could simply have the default choice be "any" (meaning no language tag), with a message that the script should not normally be selected unless your language is customarily written with multiple scripts. And *real* guidance to the user would not use suppress script -- instead it would give a choice, based on the language subtag, of what the customary values are. So it really wants to show, for example, something like: Language: zh Script: any simplified-only traditional-only other... That is, only bring up the full list of scripts in unusual cases. But all of this may vary by circumstance. If I had a library search for specialized terms, I might allow for Japanese written in Latin -- if I have content marked that way. If I am picking languages for use in resource lookup, I wouldn't even have zh-Hans listed in the above choices, since my zh content would default to that -- and the choices for region would also just list the ones that made a difference, acording to the chosen language subtag and script. And so on.... I think it would be helpful to describe in some detail some of the UI scenarios that you envision where suppress-script, and that alone, is really both necessary and sufficient to guide people in selecting language tags. Mark On 9/30/06, Frank Ellermann wrote: > > Mark Davis wrote: > > >> "And the same new applications need a licence to > >> suppress Jpan in ja-Jpan for backwards compatibility, they > >> need your proposed Suppress-Script." > > > This is untrue. I need no licence to tag anything as simply > > 'ja' (instead of ja-), if that's all I want to > > tag it with. > > You're a human user, not a "new application". It's the job of > the application to accept ja-Latn if you say so, and it could > ask "are you sure" if you say "ja-Jpan". Without a "licence" > in the form of a Suppress-Script the application would accept > ja-Latn exactly like ja-Jpan. Getting no match for any legacy > ja-JP bogeys. > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_30789_15705624.1159639983706 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't know what kind of scenario you have in mind, but for most I'm familiar with, having suppress-script in the registry is of very little aid in the UI. Let's suppose I'm picking the language in my browser. Typically I'll get a pull-down list with the most common languages. So that's already pre-canned, and -- notably -- takes some intelligence to produce. Nobody can take arbitrary combinations of language, script, and region subtags, since that would produce a huge, unusable list. Instead, someone needs to take the time to figure out which ones are worth separating out for presentation to the user. That involves *far* more than suppress-script: you need to know, for example, which region-based variations are important to separate out.

Then, if you are lucky the UI will give you a way to select additional choices (Firefox, for example, does even let you do this). A good UI will not just have the user type in some random string and validate -- it will provide pull-down menus that help to guide the user to picking reasonable choices.  (Even the choice of language subtag alone gets will get complicated with 639-3. Probably needs some fairly careful thought to allow people to get to the one they want without too much hassle.) With the UI selection for script, one could simply have the default choice be "any" (meaning no language tag), with a message that the script should not normally be selected unless your language is customarily written with multiple scripts. And *real* guidance to the user would not use suppress script -- instead it would give a choice, based on the language subtag, of what the customary values are. So it really wants to show, for example, something like:

Language: zh
Script:
   any
   simplified-only
   traditional-only
   other...

That is, only bring up the full list of scripts in unusual cases.

But all of this may vary by circumstance. If I had a library search for specialized terms, I might allow for Japanese written in Latin -- if I have content marked that way. If I am picking languages for use in resource lookup, I wouldn't even have zh-Hans listed in the above choices, since my zh content would default to that -- and the choices for region would also just list the ones that made a difference, acording to the chosen language subtag and script. And so on....

I think it would be helpful to describe in some detail some of the UI scenarios that you envision where suppress-script, and that alone, is really both necessary and sufficient to guide people in selecting language tags.

Mark

On 9/30/06, Frank Ellermann <nobody@xyzzy.claranet.de> wrote:
Mark Davis wrote:

>> "And the same new applications need a licence to
>> suppress Jpan in ja-Jpan for backwards compatibility, they
>> need your proposed Suppress-Script."

> This is untrue. I need no licence to tag anything as simply
> 'ja' (instead of ja-<somescript>), if that's all I want to
> tag it with.

You're a human user, not a "new application".  It's the job of
the application to accept ja-Latn if you say so, and it could
ask "are you sure" if you say "ja-Jpan".  Without a "licence"
in the form of a Suppress-Script the application would accept
ja-Latn exactly like ja-Jpan.  Getting no match for any legacy
ja-JP bogeys.

Frank



_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

------=_Part_30789_15705624.1159639983706-- --===============1220157663== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1220157663==-- From ltru-bounces@ietf.org Sat Sep 30 14:14:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTjMC-0007bD-BZ; Sat, 30 Sep 2006 14:14:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTjMB-0007b8-7M for ltru@ietf.org; Sat, 30 Sep 2006 14:14:35 -0400 Received: from outbound-red.frontbridge.com ([216.148.222.49] helo=outbound3-red-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTjM8-00040N-Dy for ltru@ietf.org; Sat, 30 Sep 2006 14:14:35 -0400 Received: from outbound3-red.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound3-red-R.bigfish.com (Postfix) with ESMTP id A409C858000; Sat, 30 Sep 2006 18:14:31 +0000 (UTC) Received: from mail27-red-R.bigfish.com (unknown [172.18.12.3]) by outbound3-red.bigfish.com (Postfix) with ESMTP id 9A55F857FFF; Sat, 30 Sep 2006 18:14:31 +0000 (UTC) Received: from mail27-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail27-red-R.bigfish.com (Postfix) with ESMTP id 919EB50AE84; Sat, 30 Sep 2006 18:14:31 +0000 (UTC) X-BigFish: VP Received: by mail27-red (MessageSwitch) id 1159640071498663_5295; Sat, 30 Sep 2006 18:14:31 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail27-red.bigfish.com (Postfix) with ESMTP id 70FD250AD7B; Sat, 30 Sep 2006 18:14:31 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2006093011173025-1697732 ; Sat, 30 Sep 2006 11:17:30 -0700 In-Reply-To: <6.0.0.20.2.20060930163552.09962ec0@localhost> To: Martin Duerst Subject: Re: [Ltru] Re: Suppress-Script batch 1 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 From: Karen_Broome@spe.sony.com Message-ID: Date: Sat, 30 Sep 2006 11:13:19 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 09/30/2006 11:13:20, Serialize complete at 09/30/2006 11:13:20, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 09/30/2006 11:17:30 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 09/30/2006 11:17:31 AM, Serialize complete at 09/30/2006 11:17:31 AM X-Spam-Score: 0.3 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0731980172==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0731980172== Content-Type: multipart/alternative; boundary="=_alternative 00642F5A882571F9_=" This is a multipart message in MIME format. --=_alternative 00642F5A882571F9_= Content-Type: text/plain; charset="US-ASCII" I like the "maybe even better" option the best. But again, the "preferably" irks me a bit. Is there any case where it is appropriate to use a script with spoken language? Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment Martin Duerst 09/30/2006 12:41 AM To "Mark Davis" , "Karen_Broome@spe.sony.com" cc Doug Ewell , LTRU Working Group Subject Re: [Ltru] Re: Suppress-Script batch 1 Just a very small editorial fix, otherwise +1: At 10:02 06/09/30, Mark Davis wrote: >I'm mostly in agreement with the changes, but the following goes too far: > > 6. Script subtags MUST NOT be used to identify language that is spoken or sung. Script tags and Suppress-Script fields are not applicable to such content. >If you change that to the following, it would be better. > >Script subtags not applicable to language that that is not written in characters (for example, spoken or sung). Language tags used to identify such content should not contain script tags. Please change: Script subtags not applicable to language that that is not written in characters (for example, spoken or sung). to: Script subtags are not applicable to language that that is not written in characters (for example, spoken or sung). Maybe even better: Script subtags are not applicable, and therefore preferably are left out, for content that does not use any script, for example because it is spoken or sung. This does two things: - Says explicitly that if a script tag isn't applicable, don't use it in the tag. - Makes the text somewhat more independent of the description of 'script'. (As an example, if ever we would get into the situation that sign language is recognized as a 'script', but there are not characters for it.) Not a main point, but just to be on the safe side. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 00642F5A882571F9_= Content-Type: text/html; charset="US-ASCII"
I like the "maybe even better" option the best. But again, the "preferably" irks me a bit. Is there any case where it is appropriate to use a script with spoken language?

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment


Martin Duerst <duerst@it.aoyama.ac.jp>

09/30/2006 12:41 AM

To
"Mark Davis" <mark.davis@icu-project.org>, "Karen_Broome@spe.sony.com" <Karen_Broome@spe.sony.com>
cc
Doug Ewell <dewell@adelphia.net>, LTRU Working Group <ltru@ietf.org>
Subject
Re: [Ltru] Re: Suppress-Script batch 1





Just a very small editorial fix, otherwise +1:

At 10:02 06/09/30, Mark Davis wrote:
>I'm mostly in agreement with the changes, but the following goes too far:
>
>   6.  Script subtags MUST NOT be used to identify language that is spoken or sung. Script                   tags and Suppress-Script fields are not applicable to such content.


>If you change that to the following, it would be better.
>
>Script subtags not applicable to language that that is not written in characters (for example, spoken or sung). Language tags used to identify such content should not contain script tags.

Please change:
  Script subtags not applicable to language that that is not written
  in characters (for example, spoken or sung).
to:
  Script subtags are not applicable to language that that is not
  written in characters (for example, spoken or sung).

Maybe even better:
  Script subtags are not applicable, and therefore preferably are left out,
  for content that does not use any script, for example because it is
  spoken or sung.

This does two things:
- Says explicitly that if a script tag isn't applicable, don't use it in
 the tag.
- Makes the text somewhat more independent of the description of 'script'.
 (As an example, if ever we would get into the situation that sign language
 is recognized as a 'script', but there are not characters for it.)
 Not a main point, but just to be on the safe side.

Regards,    Martin.



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


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 00642F5A882571F9_=-- --===============0731980172== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0731980172==-- From ltru-bounces@ietf.org Sat Sep 30 14:34:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTjfc-0006Dq-6k; Sat, 30 Sep 2006 14:34:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTjfb-0006Da-3I for ltru@ietf.org; Sat, 30 Sep 2006 14:34:39 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTjZT-0005oz-EN for ltru@ietf.org; Sat, 30 Sep 2006 14:28:20 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id A8B901E14B7; Sat, 30 Sep 2006 11:28:14 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 30 Sep 2006 11:28:14 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EF1A@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: "'Karen_Broome@spe.sony.com'" , Martin Duerst Subject: RE: [Ltru] Re: Suppress-Script batch 1 Date: Sat, 30 Sep 2006 11:28:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, "Preferably" and other circumlocutions have no business appearing in an Internet standard. Wherever possible, "MUST" should be used. Only when there's a compelling reason, "SHOULD" should be used. Otherwise, silence on an entire topic is more informative. It seems odd to me that people are so reluctant to get serious about "MUST NOT" where script is redundant (the predominant script) or unsuitable (non-written content). Language tags have been successfully used for a great many purposes for more than a decade entirely without script subtags. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] Sent: Saturday, September 30, 2006 2:13 PM To: Martin Duerst Cc: Doug Ewell; LTRU Working Group Subject: Re: [Ltru] Re: Suppress-Script batch 1 I like the "maybe even better" option the best. But again, the "preferably" irks me a bit. Is there any case where it is appropriate to use a script with spoken language? Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment Martin Duerst 09/30/2006 12:41 AM To"Mark Davis" , "Karen_Broome@spe.sony.com" ccDoug Ewell , LTRU Working Group SubjectRe: [Ltru] Re: Suppress-Script batch 1 Just a very small editorial fix, otherwise +1: At 10:02 06/09/30, Mark Davis wrote: >I'm mostly in agreement with the changes, but the following goes too far: > > 6. Script subtags MUST NOT be used to identify language that is spoken or sung. Script tags and Suppress-Script fields are not applicable to such content. >If you change that to the following, it would be better. > >Script subtags not applicable to language that that is not written in characters (for example, spoken or sung). Language tags used to identify such content should not contain script tags. Please change: Script subtags not applicable to language that that is not written in characters (for example, spoken or sung). to: Script subtags are not applicable to language that that is not written in characters (for example, spoken or sung). Maybe even better: Script subtags are not applicable, and therefore preferably are left out, for content that does not use any script, for example because it is spoken or sung. This does two things: - Says explicitly that if a script tag isn't applicable, don't use it in the tag. - Makes the text somewhat more independent of the description of 'script'. (As an example, if ever we would get into the situation that sign language is recognized as a 'script', but there are not characters for it.) Not a main point, but just to be on the safe side. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.12.10/459 - Release Date: 9/29/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 14:35:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTjgJ-0006Mj-Cg; Sat, 30 Sep 2006 14:35:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTjgH-0006JY-Q8 for ltru@ietf.org; Sat, 30 Sep 2006 14:35:21 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTjV3-0005NT-GF for ltru@ietf.org; Sat, 30 Sep 2006 14:23:48 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1309255nfc for ; Sat, 30 Sep 2006 11:23:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=cbTOlWVnhS+hMjuIINmUbyV5t/qMPinHAZLBDjkVfPTOj+yeXmhO4V2+SSZIQigZj1EnBi9ohZpI2Cat2QL1idlsUH0NKN1FkS/lqceUfktsb3/SyuTgPP/fxyBWk0XGbePIsBjTnPID9r2YaagEMrd60/uITj7B31Xod4y2Mkg= Received: by 10.49.80.12 with SMTP id h12mr6957150nfl; Sat, 30 Sep 2006 11:23:44 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Sat, 30 Sep 2006 11:23:44 -0700 (PDT) Message-ID: <30b660a20609301123r1253c808j3d3c61d447af26d4@mail.gmail.com> Date: Sat, 30 Sep 2006 11:23:44 -0700 From: "Mark Davis" To: "Karen_Broome@spe.sony.com" Subject: Re: [Ltru] Re: Suppress-Script batch 1 In-Reply-To: MIME-Version: 1.0 References: <30b660a20609291802l359aed85wf8464c2a569ebfdf@mail.gmail.com> X-Google-Sender-Auth: 44a4b30fd8e0b5b9 X-Spam-Score: 0.8 (/) X-Scan-Signature: 6217cd54077d488d29096a65a152105e Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1921139944==" Errors-To: ltru-bounces@ietf.org --===============1921139944== Content-Type: multipart/alternative; boundary="----=_Part_30902_7778254.1159640624026" ------=_Part_30902_7778254.1159640624026 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I had no intention to denegrate spoken language -- I use it myself. I think my wording was a bit clumsy but the goal is simply to indicate that when language is not written, the script is not necessary; when language is written, it may be necessary. There are many ways of being "not written", and one shouldn't try to enumerate all of them (spoken, sung, signed,...), but instead capture them under the term "not written" and provide examples. Martin's language avoids that but is starting to approach the tautology: => don't use scripts when they aren't necessary => don't use X when X is not necessary. Mark On 9/29/06, Karen_Broome@spe.sony.com wrote: > > > Hmm.... I can tell you that I have had to make this a hard, fast -- if > behind-the-scenes -- rule in my industry. > > Just in terms of feature films: When there is one application language > list serving original production language as well as dubbed and subtitled > versions, the dubbed content is inevitably either marked "Traditional > Mandarin Chinese" or "Simplified Mandarin Chinese" -- or subtitles are > classified as "Mandarin" or "Chinese," which is useless when trying to find > the right version to ship to a particular region. It's bad data. > > I think that's how I landed in LTRU in the first place: I illustrated a > need in my industry to maintain two unique language lists in applications or > products that deal with both types of language. This is somewhat of a > usability issue more than an identification issue, but I don't want to see a > list that looks like > > Language: > > Chinese (Mandarin) > Chinese (Mandarin, Simplified) > Chinese (Mandarin, Traditional) > > That results in junk data when used by the average classifier of original, > dubbed, or subtitled content because the categories are not mutually > exclusive. I want to see two unique lists in a UI: > > Spoken Language: > > Chinese (Mandarin) = zh-cmn > > Written Language > > Chinese (Mandarin, Simplified) = zh-cmn-Hans > Chinese (Mandarin, Traditional) = zh-cmn-Hant > > If we had a film that had an original language of Cantonese with subtitles > in Mandarin with simplified orthography, we would identify both "zh-yue" as > a spoken language (type = original) and the "zh-cmn-Hans" written language > (type = subtitles). In the case you mention, we would identify all written > and spoken variants in the multimedia document -- a video in a web page > could have a different tag than the page itself. DVDs can feature several > subtitle and dubbing options on the same disk. The distinction between > written and spoken languages is common in most standards that deal with > audiovisual content, and it's assumed that many works will have more than > one language code assigned. > > Would you be any more comfortable with a "should not"? Your text to me > seems to again define spoken language as the edge case -- language that is > not written in characters. It's not written at all! I'd rather come straight > out and acknowledge that in reality most language is spoken -- and > increasingly technology allows that spoken language to be captured -- over a > watered-down mention of spoken language as a "for example" in parentheses. > > Regards, > > Karen Broome > Metadata Systems Designer > Sony Pictures Entertainment > 310.244.4384 > > > *"Mark Davis" * > > 09/29/2006 06:02 PM > To > "Karen_Broome@spe.sony.com" cc > Doug Ewell , LTRU Working Group > Subject > Re: [Ltru] Re: Suppress-Script batch 1 > > > > > > > I'm mostly in agreement with the changes, but the following goes too far: > > 6. Script subtags MUST NOT be used to identify language that is spoken > or sung. Script tags and Suppress-Script fields are not > applicable to such content. > > Nowhere else do we say that "X cannot be used to identify Y", and with > good reason. We are in the business of providing a clear mechanism for > representing identifiers for languages, but we are *not* in the business of > policing which content gets tagged with which tags. There are also too many > edge cases. If I tagged a multimedia document with zh-Hant and the document > happened to contain a snipped of spoken Chinese -- or for that matter, > spoken English -- I would not be compliant to BCP 47! > > If you change that to the following, it would be better. > > Script subtags not applicable to language that that is not written in > characters (for example, spoken or sung). Language tags used to identify > such content should not contain script tags. > > Mark > > > On 9/29/06, *Karen_Broome@spe.sony.com* <* > Karen_Broome@spe.sony.com* > wrote: > > Changes to clarify use of script tags and RFC 4646bis with spoken > language: > > -Section 1- > > "In addition, knowledge about the particular language used by some > piece of information content might be useful or even required by some > types of processing; for example, spell-checking, computer- > synthesized speech, Braille transcription, or high-quality print > renderings." > > ADD after previous paragraph? > > It is important to note that the language identification needs described > above apply not only to written language, but also to spoken language such > that found in videos, audio files, songs, podcasts, films, and written > interfaces used to access or classify such content. > > -Section 2.2.3- > > Changes: > > 2. When applicable, 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. > > ADD: > > 6. Script subtags MUST NOT be used to identify language that is spoken > or sung. Script tags and Suppress-Script fields are not > applicable to such content. > > -Section 4.1- > > 2. ... > > * For example, the subtag '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 document were written in English mixing Latin > script with another script such as Braille ('Brai'), then it might be > appropriate to choose to indicate > both scripts to aid in content selection, such as the application of a > style sheet. On the other hand, the subtags 'Hant' and 'Hans' should > not be used to describe an audiovisual asset in Chinese unless the language > appears in written subtitles or captions. > > > I'm still checking to see if there are any other opportunities for > clarification. > > Regards, > > Karen Broome > Metadata Systems Designer > Sony Pictures Entertainment > 310.244.4384 > > > > *Martin Duerst <**duerst@it.aoyama.ac.jp* *>* > > 09/27/2006 06:48 PM > > To > *Karen_Broome@spe.sony.com* , "Doug Ewell" <* > dewell@adelphia.net* >, "LTRU Working Group" <* > ltru@ietf.org* > cc > > Subject > Re: [Ltru] Re: Suppress-Script batch 1 > > > > > > > > > Hello Karen, > > As a technical contributor, I think you raise a very valid > point that should be documented clearly. > > As a co-chair, I'd like to ask you to propose specific wording, > and a place to put it. This is the fastest way to move this > issue forward. > > Regards, Martin. > > At 02:52 06/09/28, *Karen_Broome@spe.sony.com* wrote: > > >I still think the text of RFC 4646 and structure leans strongly toward an > assumption that all language is written. Increasingly web content features > animated talking heads or video, and this content may need language tagging > as well. > > > >Motion picture applications -- including television, broadcast, Digital > Cinema, podcast, phonecast, multilingual electronic program guides, and > local/national/university archives -- also require language tagging. The > text of RFC 4646 indicates that the script can be omitted when it can be > assumed. It doesn't mention that in an increasing number of cases, the > assignment of a script tag is completely inappropriate. > > > >Regards, > > > >Karen Broome > >Metadata Systems Designer > >Sony Pictures Entertainment > > > > > > > > > > > >"Doug Ewell" <*dewell@adelphia.net* > > > > >09/27/2006 10:15 AM > >To > >"LTRU Working Group" <*ltru@ietf.org* > > >cc > >Subject > >[Ltru] Re: Suppress-Script batch 1 > > > > > > > > > >John Cowan wrote: > > > >> Remember that the criterion for including a Suppress-Script is that > >> the script is always used for the language except in a few highly > >> restricted domains, such as writing for the blind, scholarly > >> transliteration, transcription for use in another language, and when > >> the standard script is not available. > > > >I wish we had that explanation somewhere in RFC 4646. It's better than > >most of the explanations I've seen, certainly better than any I've > >written. > > > >-- > >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 > >*Ltru@ietf.org* > >*https://www1.ietf.org/mailman/listinfo/ltru* > > > > > >_______________________________________________ > >Ltru mailing list > >*Ltru@ietf.org* > >*https://www1.ietf.org/mailman/listinfo/ltru* > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# *http://www.sw.it.aoyama.ac.jp* > mailto:* duerst@it.aoyama.ac.jp* > > > _______________________________________________ > Ltru mailing list* > **Ltru@ietf.org* * > **https://www1.ietf.org/mailman/listinfo/ltru* > > > > _______________________________________________ > Ltru mailing list* > **Ltru@ietf.org* * > **https://www1.ietf.org/mailman/listinfo/ltru* > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > ------=_Part_30902_7778254.1159640624026 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I had no intention to denegrate spoken language -- I use it myself. I think my wording was a bit clumsy but the goal is simply to indicate that when language is not written, the script is not necessary; when language is written, it may be necessary. There are many ways of being "not written", and one shouldn't try to enumerate all of them (spoken, sung, signed,...), but instead capture them under the term "not written" and provide examples.

Martin's language avoids that but is starting to approach the tautology: => don't use scripts when they aren't necessary => don't use X when X is not necessary.

Mark

On 9/29/06, Karen_Broome@spe.sony.com <Karen_Broome@spe.sony.com> wrote:

Hmm.... I can tell you that I have had to make this a hard, fast -- if behind-the-scenes -- rule in my industry.  

Just in terms of feature films: When there is one application language list serving original production language as well as dubbed and subtitled versions, the dubbed content is inevitably either marked "Traditional Mandarin Chinese" or "Simplified Mandarin Chinese"  -- or subtitles are classified as "Mandarin" or "Chinese," which is useless when trying to find the right version to ship to a particular region. It's bad data.

I think that's how I landed in LTRU in the first place: I illustrated a need in my industry to maintain two unique language lists in applications or products that deal with both types of language. This is somewhat of a usability issue more than an identification issue, but I don't want to see a list that looks like

Language:

Chinese (Mandarin)
Chinese (Mandarin, Simplified)
Chinese (Mandarin, Traditional)

That results in junk data when used by the average classifier of original, dubbed, or subtitled content because the categories are not mutually exclusive. I want to see two unique lists in a UI:

Spoken Language:

        Chinese (Mandarin) = zh-cmn

Written Language

        Chinese (Mandarin, Simplified) = zh-cmn-Hans
        Chinese (Mandarin, Traditional) = zh-cmn-Hant

If we had a film that had an original language of Cantonese with subtitles in Mandarin with simplified orthography, we would identify both "zh-yue" as a spoken language (type = original) and the "zh-cmn-Hans" written language (type = subtitles). In the case you mention, we would identify all written and spoken variants in the multimedia document -- a video in a web page could have a different tag than the page itself. DVDs can feature several subtitle and dubbing options on the same disk. The distinction between written and spoken languages is common in most standards that deal with audiovisual content, and it's assumed that many works will have more than one language code assigned.

Would you be any more comfortable with a "should not"? Your text to me seems to again define spoken language as the edge case -- language that is not written in characters. It's not written at all! I'd rather come straight out and acknowledge that in reality most language is spoken -- and increasingly technology allows that spoken language to be captured -- over a watered-down mention of spoken language as a "for example" in parentheses.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384


"Mark Davis" <mark.davis@icu-project.org>

09/29/2006 06:02 PM

To
"Karen_Broome@spe.sony.com" <Karen_Broome@spe.sony.com>
cc
Doug Ewell <dewell@adelphia.net>, LTRU Working Group <ltru@ietf.org>
Subject
Re: [Ltru] Re: Suppress-Script batch 1







I'm mostly in agreement with the changes, but the following goes too far:

  6.  Script subtags MUST NOT be used to identify language that is spoken or sung. Script                   tags and Suppress-Script fields are not applicable to such content.

Nowhere else do we say that "X cannot be used to identify Y", and with good reason. We  are in the business of providing a clear mechanism for representing identifiers for languages, but we are *not* in the business of policing which content gets tagged with which tags. There are also too many edge cases. If I tagged a multimedia document with zh-Hant and the document happened to contain a snipped of spoken Chinese -- or for that matter, spoken English -- I would not be compliant to BCP 47!

If you change that to the following, it would be better.

Script subtags not applicable to language that that is not written in characters (for example, spoken or sung). Language tags used to identify such content should not contain script tags.

Mark
On 9/29/06, Karen_Broome@spe.sony.com <Karen_Broome@spe.sony.com> wrote:

Changes to clarify use of script tags and RFC 4646bis with spoken language:

-Section 1-

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

ADD after previous paragraph?

It is important to note that the language identification needs described above apply not only to written language, but also to spoken language such that found in videos, audio files, songs, podcasts, films, and written interfaces used to access or classify such content.

-Section 2.2.3-

Changes:

2.  <ADD>When applicable,</ADD> 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.

ADD:

  6.  Script subtags MUST NOT be used to identify language that is spoken or sung. Script                   tags and Suppress-Script fields are not applicable to such content.

-Section 4.1-

2.  ...

*  For example, the subtag '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 document were written in English mixing Latin script with another script such as Braille ('Brai'), then it might be appropriate to choose to indicate
both scripts to aid in content selection, such as the application of a style sheet. <ADD> On the other hand, the subtags 'Hant' and 'Hans' should not be used to describe an audiovisual asset in Chinese unless the language appears in written subtitles or captions.</ADD>


I'm still checking to see if there are any other opportunities for clarification.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384



Martin Duerst < duerst@it.aoyama.ac.jp>

09/27/2006 06:48 PM


To
Karen_Broome@spe.sony.com , "Doug Ewell" <dewell@adelphia.net >, "LTRU Working Group" <ltru@ietf.org >
cc
Subject
Re: [Ltru] Re: Suppress-Script batch 1









Hello Karen,

As a technical contributor, I think you raise a very valid
point that should be documented clearly.

As a co-chair, I'd like to ask you to propose specific wording,
and a place to put it. This is the fastest way to move this
issue forward.

Regards,    Martin.

At 02:52 06/09/28, Karen_Broome@spe.sony.com wrote:

>I still think the text of RFC 4646 and structure leans strongly toward an assumption that all language is written. Increasingly web content features animated talking heads or video, and this content may need language tagging as well.
>
>Motion picture applications -- including television, broadcast, Digital Cinema, podcast, phonecast, multilingual electronic program guides, and local/national/university archives -- also require language tagging. The text of RFC 4646 indicates that the script can be omitted when it can be assumed. It doesn't mention that in an increasing number of cases, the assignment of a script tag is completely inappropriate.
>
>Regards,
>
>Karen Broome
>Metadata Systems Designer
>Sony Pictures Entertainment
>
>
>
>
>
>"Doug Ewell" <dewell@adelphia.net >
>
>09/27/2006 10:15 AM
>To
>"LTRU Working Group" <ltru@ietf.org >
>cc
>Subject
>[Ltru] Re: Suppress-Script batch 1
>
>
>
>
>John Cowan <cowan at ccil dot org> wrote:
>
>> Remember that the criterion for including a Suppress-Script is that
>> the script is always used for the language except in a few highly
>> restricted domains, such as writing for the blind, scholarly
>> transliteration, transcription for use in another language, and when
>> the standard script is not available.
>
>I wish we had that explanation somewhere in RFC 4646.  It's better than
>most of the explanations I've seen, certainly better than any I've
>written.
>
>--
>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
>Ltru@ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru
>
>
>_______________________________________________
>Ltru mailing list
>Ltru@ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


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


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru



_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

------=_Part_30902_7778254.1159640624026-- --===============1921139944== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1921139944==-- From ltru-bounces@ietf.org Sat Sep 30 14:41:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTjmB-0000di-L3; Sat, 30 Sep 2006 14:41:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTjmB-0000dd-0F for ltru@ietf.org; Sat, 30 Sep 2006 14:41:27 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTjm9-0007OT-OE for ltru@ietf.org; Sat, 30 Sep 2006 14:41:26 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060930184123.BBNQ28964.mta10.adelphia.net@DGBP7M81>; Sat, 30 Sep 2006 14:41:23 -0400 Message-ID: <007801c6e4c0$071e7c50$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <30b660a20609291802l359aed85wf8464c2a569ebfdf@mail.gmail.com> <30b660a20609301123r1253c808j3d3c61d447af26d4@mail.gmail.com> Subject: Re: [Ltru] Re: Suppress-Script batch 1 Date: Sat, 30 Sep 2006 11:41:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Karen_Broome@spe.sony.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > Martin's language avoids that but is starting to approach the > tautology: => don't use scripts when they aren't necessary => don't > use X when X is not necessary. I think that tautology is entirely appropriate. It's consistent with what we've been saying all along. Don't use script subtags when they aren't necessary; don't use region subtags when they aren't necessary; tag content wisely. -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 15:18:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTkMD-000647-7Z; Sat, 30 Sep 2006 15:18:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTkMB-00063z-Sv for ltru@ietf.org; Sat, 30 Sep 2006 15:18:39 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTkMA-00015H-H5 for ltru@ietf.org; Sat, 30 Sep 2006 15:18:39 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1315311nfc for ; Sat, 30 Sep 2006 12:18:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=f4A1f5QJA7l6zQ9Xa4KddUHOFIAXUhKzlpbLMagv5Rofg10GQyR6VIVHYcFvEZsrruhnJG8BUhSI93+oC41lLaS8uPSfhsqFuJfJ6lI6XctmKoRvAoFi34GQZjZJ9Qbg2+Q78CKnP4v03FlDx+YHrn4lJbv2gUQDZDf6G86k4vs= Received: by 10.49.91.6 with SMTP id t6mr7029098nfl; Sat, 30 Sep 2006 12:18:36 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Sat, 30 Sep 2006 12:18:36 -0700 (PDT) Message-ID: <30b660a20609301218g5c7db7d8yb326fc2e0fbf4bd8@mail.gmail.com> Date: Sat, 30 Sep 2006 12:18:36 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Suppress-Script batch 1 In-Reply-To: <007801c6e4c0$071e7c50$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <30b660a20609291802l359aed85wf8464c2a569ebfdf@mail.gmail.com> <30b660a20609301123r1253c808j3d3c61d447af26d4@mail.gmail.com> <007801c6e4c0$071e7c50$6401a8c0@DGBP7M81> X-Google-Sender-Auth: 3dbd9bc1c015075d X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Karen_Broome@spe.sony.com, LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1782999855==" Errors-To: ltru-bounces@ietf.org --===============1782999855== Content-Type: multipart/alternative; boundary="----=_Part_31330_4023448.1159643916457" ------=_Part_31330_4023448.1159643916457 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline "X is not necessary when X is not necessary" is never worth adding to a document, no matter what the X is. Mark On 9/30/06, Doug Ewell wrote: > > Mark Davis wrote: > > > Martin's language avoids that but is starting to approach the > > tautology: => don't use scripts when they aren't necessary => don't > > use X when X is not necessary. > > I think that tautology is entirely appropriate. It's consistent with > what we've been saying all along. Don't use script subtags when they > aren't necessary; don't use region subtags when they aren't necessary; > tag content wisely. > > -- > 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 > > ------=_Part_31330_4023448.1159643916457 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline "X is not necessary when X is not necessary" is never worth adding to a document, no matter what the X is.

Mark

On 9/30/06, Doug Ewell < dewell@adelphia.net> wrote:
Mark Davis wrote:

> Martin's language avoids that but is starting to approach the
> tautology: => don't use scripts when they aren't necessary => don't
> use X when X is not necessary.

I think that tautology is entirely appropriate.  It's consistent with
what we've been saying all along.  Don't use script subtags when they
aren't necessary; don't use region subtags when they aren't necessary;
tag content wisely.

--
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


------=_Part_31330_4023448.1159643916457-- --===============1782999855== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1782999855==-- From ltru-bounces@ietf.org Sat Sep 30 15:46:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTknT-0000Dm-ON; Sat, 30 Sep 2006 15:46:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTknS-0000Df-9z for ltru@ietf.org; Sat, 30 Sep 2006 15:46:50 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTknQ-0003iF-V8 for ltru@ietf.org; Sat, 30 Sep 2006 15:46:50 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060930194644.YERL437.mta13.adelphia.net@DGBP7M81>; Sat, 30 Sep 2006 15:46:44 -0400 Message-ID: <007f01c6e4c9$283ec6c0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <30b660a20609291802l359aed85wf8464c2a569ebfdf@mail.gmail.com> <30b660a20609301123r1253c808j3d3c61d447af26d4@mail.gmail.com> <007801c6e4c0$071e7c50$6401a8c0@DGBP7M81> <30b660a20609301218g5c7db7d8yb326fc2e0fbf4bd8@mail.gmail.com> Subject: Re: [Ltru] Re: Suppress-Script batch 1 Date: Sat, 30 Sep 2006 12:46:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Karen_Broome@spe.sony.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > "X is not necessary when X is not necessary" is never worth adding to > a document, no matter what the X is. We are talking about "Don't use X when X is not necessary," which is not the same thing. There are many situations, in computer applications and real life, when it is perfectly OK to do something that is not strictly necessary. Sometimes it is even preferable for some security or verification reason. In the C or C++ or C# programming languages, I can write: if (x == 0) { do_something(); } else { do_something_else(); } or I can write the same thing without the curly braces. There are certain reasons (stylistic or maintenance) why the version with "unnecessary" braces might be preferable. I don't see any harm in pointing out that script (and region) subtags do not fall into this category. -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 15:50:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTkqY-0001Te-Eu; Sat, 30 Sep 2006 15:50:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTkqW-0001TN-MI for ltru@ietf.org; Sat, 30 Sep 2006 15:50:00 -0400 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTkqT-000440-Rt for ltru@ietf.org; Sat, 30 Sep 2006 15:50:00 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1319077nfc for ; Sat, 30 Sep 2006 12:49:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=fwrliYlg0/5yU/v60yr4NHEKDSuVMFp1ESpT/ih2vpgpJjofQYGYOEPTafH0XTA0v34jhyhMLcpJblC8JcMho2gSp97jDHpGJh3+KfUIN3hosbrCy8Qoqx7wwhjlaGzf7UoiX2GRgGyyykEMgp09TDKgYVC7Wdb8jDkHn2r69jg= Received: by 10.49.29.3 with SMTP id g3mr3469641nfj; Sat, 30 Sep 2006 12:49:55 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Sat, 30 Sep 2006 12:49:55 -0700 (PDT) Message-ID: <30b660a20609301249s39fbed9ew9e3454310f3c7d46@mail.gmail.com> Date: Sat, 30 Sep 2006 12:49:55 -0700 From: "Mark Davis" To: "McDonald, Ira" Subject: Re: [Ltru] Re: Suppress-Script batch 1 In-Reply-To: <789E617C880666438EDEE30C2A3E8D10EF1A@mailsrvnt05.enet.sharplabs.com> MIME-Version: 1.0 References: <789E617C880666438EDEE30C2A3E8D10EF1A@mailsrvnt05.enet.sharplabs.com> X-Google-Sender-Auth: 7ffdf711c58f5d1e X-Spam-Score: 0.5 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: Doug Ewell , "Karen_Broome@spe.sony.com" , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1397013226==" Errors-To: ltru-bounces@ietf.org --===============1397013226== Content-Type: multipart/alternative; boundary="----=_Part_31710_27712285.1159645795684" ------=_Part_31710_27712285.1159645795684 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline > Otherwise, silence on an entire topic is more informative. Your statement is very difficult to understand. There are many many statements in RFCs that don't contain or contribute to a (MUST|SHOULD) [NOT]. Otherwise the RFC as a whole be impossible to read and apply effectively. There is a place for informative discourse in standards, and there is a place for recommendations that are guidance, but are not as strong as a SHOULD. > Language tags have been successfully used for a great many purposes for more than a decade entirely without script subtags. If there had not been good reason for introducing the many features of 4646 that were not in 3066, including scripts, we wouldn't have done it. Rereading some of the material on Addison's website would be useful about the reasons may be useful for you. Look, we all agree that it is not very useful to tag anything with fr-Latn-AQ or en-Hira-BV. Our goal is to specify what those tags would mean, so that they can be correctly interpreted if they are received, and and give general guidance as to when particular combinations should only be used in specialized contexts. Beyond that, it's pointless. Let's not make up problems where they don't exist. I see no groundswell, nor any realistic prospect of a groundswell, of people tagging languages with unnecessary scripts. I didn't oppose Suppress-Script because it is basically harmless, even though in practice it is of very little real use. But if it becomes a maintenence nightmare tagging 7000-odd scripts with correct values in the absence of good data, it is no longer harmless. Now, this is all getting away from Karen's quite reasonable desire to provide people more clarity on the fact that for material that is only non-written it isn't a good idea to include a script subtag. I could even see, in some applications, tagging records with, for example, zh-Zxxx, meaning unwritten Chinese. Then I could search records for zh (meaning any zh, no matter whether spoken, or written in traditional, or written in simplified, or written in pinyin), or filter that to only non-written, or only simplified, or only romanized. Mark On 9/30/06, McDonald, Ira wrote: > > Hi, > > "Preferably" and other circumlocutions have no business > appearing in an Internet standard. Wherever possible, > "MUST" should be used. Only when there's a compelling > reason, "SHOULD" should be used. Otherwise, silence on > an entire topic is more informative. > > It seems odd to me that people are so reluctant to get > serious about "MUST NOT" where script is redundant (the > predominant script) or unsuitable (non-written content). > > Language tags have been successfully used for a great > many purposes for more than a decade entirely without > script subtags. > > Cheers, > - Ira > > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com > -----Original Message----- > From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] > Sent: Saturday, September 30, 2006 2:13 PM > To: Martin Duerst > Cc: Doug Ewell; LTRU Working Group > Subject: Re: [Ltru] Re: Suppress-Script batch 1 > > > > I like the "maybe even better" option the best. But again, the > "preferably" > irks me a bit. Is there any case where it is appropriate to use a script > with spoken language? > > Regards, > > Karen Broome > Metadata Systems Designer > Sony Pictures Entertainment > > > > Martin Duerst > 09/30/2006 12:41 AM To"Mark Davis" , > "Karen_Broome@spe.sony.com" > ccDoug Ewell , LTRU Working Group > SubjectRe: [Ltru] Re: Suppress-Script batch 1 > > > > > > > > Just a very small editorial fix, otherwise +1: > > At 10:02 06/09/30, Mark Davis wrote: > >I'm mostly in agreement with the changes, but the following goes too far: > > > > 6. Script subtags MUST NOT be used to identify language that is > spoken > or sung. Script tags and Suppress-Script fields are not > applicable to such content. > > > >If you change that to the following, it would be better. > > > >Script subtags not applicable to language that that is not written in > characters (for example, spoken or sung). Language tags used to identify > such content should not contain script tags. > > Please change: > Script subtags not applicable to language that that is not written > in characters (for example, spoken or sung). > to: > Script subtags are not applicable to language that that is not > written in characters (for example, spoken or sung). > > Maybe even better: > Script subtags are not applicable, and therefore preferably are left > out, > for content that does not use any script, for example because it is > spoken or sung. > > This does two things: > - Says explicitly that if a script tag isn't applicable, don't use it in > the tag. > - Makes the text somewhat more independent of the description of 'script'. > (As an example, if ever we would get into the situation that sign language > is recognized as a 'script', but there are not characters for it.) > Not a main point, but just to be on the safe side. > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.1.407 / Virus Database: 268.12.10/459 - Release Date: 9/29/2006 > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_31710_27712285.1159645795684 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline > Otherwise, silence on an entire topic is more informative.

Your statement is very difficult to understand. There are many many statements in RFCs that don't contain or contribute to a (MUST|SHOULD) [NOT]. Otherwise the RFC as a whole be impossible to read and apply effectively. There is a place for informative discourse in standards, and there is a place for recommendations that are guidance, but are not as strong as a SHOULD.

> Language tags have been successfully used for a great
many purposes for more than a decade entirely without
script subtags.

If there had not been good reason for introducing the many features of 4646 that were not in 3066, including scripts, we wouldn't have done it. Rereading some of the material on Addison's website would be useful about the reasons may be useful for you.

Look, we all agree that it is not very useful to tag anything with fr-Latn-AQ or en-Hira-BV. Our goal is to specify what those tags would mean, so that they can be correctly interpreted if they are received, and and give general guidance as to when particular combinations should only be used in specialized contexts. Beyond that, it's pointless.

Let's not make up problems where they don't exist. I see no groundswell, nor any realistic prospect of a groundswell, of people tagging languages with unnecessary scripts. I didn't oppose Suppress-Script because it is basically harmless, even though in practice it is of very little real use. But if it becomes a maintenence nightmare tagging 7000-odd scripts with correct values in the absence of good data, it is no longer harmless.


Now, this is all getting away from Karen's quite reasonable desire to provide people more clarity on the fact that for material that is only non-written it isn't a good idea to include a script subtag. I could even see, in some applications, tagging records with, for example, zh-Zxxx, meaning unwritten Chinese. Then I could search records for zh (meaning any zh, no matter whether spoken, or written in traditional, or written in simplified, or written in pinyin), or filter that to only non-written, or only simplified, or only romanized.

Mark


On 9/30/06, McDonald, Ira <imcdonald@sharplabs.com> wrote:
Hi,

"Preferably" and other circumlocutions have no business
appearing in an Internet standard.  Wherever possible,
"MUST" should be used.  Only when there's a compelling
reason, "SHOULD" should be used.  Otherwise, silence on
an entire topic is more informative.

It seems odd to me that people are so reluctant to get
serious about "MUST NOT" where script is redundant (the
predominant script) or unsuitable (non-written content).

Language tags have been successfully used for a great
many purposes for more than a decade entirely without
script subtags.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
-----Original Message-----
From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com]
Sent: Saturday, September 30, 2006 2:13 PM
To: Martin Duerst
Cc: Doug Ewell; LTRU Working Group
Subject: Re: [Ltru] Re: Suppress-Script batch 1



I like the "maybe even better" option the best. But again, the "preferably"
irks me a bit. Is there any case where it is appropriate to use a script
with spoken language?

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment



Martin Duerst <duerst@it.aoyama.ac.jp>
09/30/2006 12:41 AM To"Mark Davis" < mark.davis@icu-project.org>,
"Karen_Broome@spe.sony.com" <Karen_Broome@spe.sony.com >
ccDoug Ewell <dewell@adelphia.net>, LTRU Working Group <ltru@ietf.org>
SubjectRe: [Ltru] Re: Suppress-Script batch 1







Just a very small editorial fix, otherwise +1:

At 10:02 06/09/30, Mark Davis wrote:
>I'm mostly in agreement with the changes, but the following goes too far:
>
>   6.  Script subtags MUST NOT be used to identify language that is spoken
or sung. Script                   tags and Suppress-Script fields are not
applicable to such content.


>If you change that to the following, it would be better.
>
>Script subtags not applicable to language that that is not written in
characters (for example, spoken or sung). Language tags used to identify
such content should not contain script tags.

Please change:
  Script subtags not applicable to language that that is not written
  in characters (for example, spoken or sung).
to:
  Script subtags are not applicable to language that that is not
  written in characters (for example, spoken or sung).

Maybe even better:
  Script subtags are not applicable, and therefore preferably are left out,
  for content that does not use any script, for example because it is
  spoken or sung.

This does two things:
- Says explicitly that if a script tag isn't applicable, don't use it in
the tag.
- Makes the text somewhat more independent of the description of 'script'.
(As an example, if ever we would get into the situation that sign language
is recognized as a 'script', but there are not characters for it.)
Not a main point, but just to be on the safe side.

Regards,    Martin.



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



_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.407 / Virus Database: 268.12.10/459 - Release Date: 9/29/2006


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

------=_Part_31710_27712285.1159645795684-- --===============1397013226== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1397013226==-- From ltru-bounces@ietf.org Sat Sep 30 15:51:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTksD-00023S-UY; Sat, 30 Sep 2006 15:51:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTksC-00023K-UB for ltru@ietf.org; Sat, 30 Sep 2006 15:51:44 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTksB-0004Fl-OI for ltru@ietf.org; Sat, 30 Sep 2006 15:51:44 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GTks8-0000el-LH; Sat, 30 Sep 2006 15:51:40 -0400 Date: Sat, 30 Sep 2006 15:51:40 -0400 To: Mark Davis Subject: Re: [Ltru] Re: Suppress-Script batch 1 Message-ID: <20060930195140.GA1769@ccil.org> References: <30b660a20609291802l359aed85wf8464c2a569ebfdf@mail.gmail.com> <30b660a20609301123r1253c808j3d3c61d447af26d4@mail.gmail.com> <007801c6e4c0$071e7c50$6401a8c0@DGBP7M81> <30b660a20609301218g5c7db7d8yb326fc2e0fbf4bd8@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20609301218g5c7db7d8yb326fc2e0fbf4bd8@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > "X is not necessary when X is not necessary" is never worth adding to a > document, no matter what the X is. It's like those signs "UNAUTHORIZED PERSONNEL FORBIDDEN", which boil down to "People who are not authorized to be here are not authorized to be here." Yet such signs are useful. In this case, the message is "Don't *use* unnecessary subtags -- they are not harmless." -- Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x) Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! -- Joyce, Ulysses, "Oxen of the Sun" cowan@ccil.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 15:52:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTktB-0002bt-86; Sat, 30 Sep 2006 15:52:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTktA-0002bo-0A for ltru@ietf.org; Sat, 30 Sep 2006 15:52:44 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTkt8-0004Xw-J3 for ltru@ietf.org; Sat, 30 Sep 2006 15:52:43 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1319361nfc for ; Sat, 30 Sep 2006 12:52:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=WPCZ3G9D1RcmiDsLvhtaUNh03mlLvtcVmVbwRTNs+OIt6g1AogCbGsPFQ0QtY9fdGUFpIh9zd23Oc7f7PHPuFOdoteeRZoKN8vs1KMidPwnZQ6CXBA2vTIxP6Ez8Qe2Uu7o1jp47I6K7brA/zIr7m4hV0JVvCXqtMbcO06VRg/8= Received: by 10.49.29.3 with SMTP id g3mr3472971nfj; Sat, 30 Sep 2006 12:52:38 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Sat, 30 Sep 2006 12:52:38 -0700 (PDT) Message-ID: <30b660a20609301252o63b63296i797c54c98d95e20b@mail.gmail.com> Date: Sat, 30 Sep 2006 12:52:38 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Suppress-Script batch 1 In-Reply-To: <007f01c6e4c9$283ec6c0$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <30b660a20609291802l359aed85wf8464c2a569ebfdf@mail.gmail.com> <30b660a20609301123r1253c808j3d3c61d447af26d4@mail.gmail.com> <007801c6e4c0$071e7c50$6401a8c0@DGBP7M81> <30b660a20609301218g5c7db7d8yb326fc2e0fbf4bd8@mail.gmail.com> <007f01c6e4c9$283ec6c0$6401a8c0@DGBP7M81> X-Google-Sender-Auth: f3ce90682d8c272e X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Karen_Broome@spe.sony.com, LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1665321106==" Errors-To: ltru-bounces@ietf.org --===============1665321106== Content-Type: multipart/alternative; boundary="----=_Part_31734_4644497.1159645958220" ------=_Part_31734_4644497.1159645958220 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline We are arguing about angels on the head of a pin. I'm saying, it is MORE informative to say Don't use script subtags when they are not necessary or inappropriate, such as for non-written content. Such content may include spoken or sung language. than it is to say. Don't use script subtags when they are not necessary. Mark On 9/30/06, Doug Ewell wrote: > > Mark Davis wrote: > > > "X is not necessary when X is not necessary" is never worth adding to > > a document, no matter what the X is. > > We are talking about "Don't use X when X is not necessary," which is not > the same thing. There are many situations, in computer applications and > real life, when it is perfectly OK to do something that is not strictly > necessary. Sometimes it is even preferable for some security or > verification reason. > > In the C or C++ or C# programming languages, I can write: > > if (x == 0) > { > do_something(); > } > else > { > do_something_else(); > } > > or I can write the same thing without the curly braces. There are > certain reasons (stylistic or maintenance) why the version with > "unnecessary" braces might be preferable. > > I don't see any harm in pointing out that script (and region) subtags do > not fall into this category. > > -- > 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 > > ------=_Part_31734_4644497.1159645958220 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline We are arguing about angels on the head of a pin. I'm saying, it is MORE informative to say

Don't use script subtags when they are not necessary or inappropriate, such as for non-written content. Such content may include spoken or sung language.

than it is to say.

Don't use script subtags when they are not necessary.

Mark

On 9/30/06, Doug Ewell < dewell@adelphia.net> wrote:
Mark Davis wrote:

> "X is not necessary when X is not necessary" is never worth adding to
> a document, no matter what the X is.

We are talking about "Don't use X when X is not necessary," which is not
the same thing.  There are many situations, in computer applications and
real life, when it is perfectly OK to do something that is not strictly
necessary.  Sometimes it is even preferable for some security or
verification reason.

In the C or C++ or C# programming languages, I can write:

if (x == 0)
{
    do_something();
}
else
{
    do_something_else();
}

or I can write the same thing without the curly braces.  There are
certain reasons (stylistic or maintenance) why the version with
"unnecessary" braces might be preferable.

I don't see any harm in pointing out that script (and region) subtags do
not fall into this category.

--
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


------=_Part_31734_4644497.1159645958220-- --===============1665321106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1665321106==-- From ltru-bounces@ietf.org Sat Sep 30 17:04:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTm0D-0005Oz-RN; Sat, 30 Sep 2006 17:04:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTm0C-0005Ou-Hu for ltru@lists.ietf.org; Sat, 30 Sep 2006 17:04:04 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTm0B-0003a8-43 for ltru@lists.ietf.org; Sat, 30 Sep 2006 17:04:04 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GTm01-0001sf-Bh for ltru@lists.ietf.org; Sat, 30 Sep 2006 23:03:53 +0200 Received: from du-001-068.access.de.clara.net ([212.82.227.68]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Sep 2006 23:03:53 +0200 Received: from nobody by du-001-068.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Sep 2006 23:03:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 30 Sep 2006 23:00:51 +0200 Organization: Lines: 59 Message-ID: <451EDB03.7048@xyzzy.claranet.de> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> <6.0.0.20.2.20060928193237.08122670__32691.3689300001$1159440247$gmane$org@localhost> <451C66A3.52C9@xyzzy.claranet.de> <30b660a20609281824m560066c0k1202af61d673e724@mail.gmail.com> <451C899C.3C0E@xyzzy.claranet.de> <30b660a20609290740nc2c3f8bp7985c80202a7d7f@mail.gmail.com> <451E63F9.2CA8@xyzzy.claranet.de> <30b660a20609301113t7330ca8cqc848d4ddbb758a10@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-068.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Subject: [Ltru] Re: Korean (and Japanese) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > I don't know what kind of scenario you have in mind Lazy / clueless implementor + clueless user / tagger. As an example I had no clue that Jpan might be a good Suppress-Script for jp. > Typically I'll get a pull-down list with the most > common languages. So that's already pre-canned My browser didn't know de-CH-1996. Admittedly I somehow managed to disable its Accept-Language and don't know how to enable it again, but in theory I'd have to configure it manually. BTW, the stunt to screw-up the Accept-Language was a side effect of Google's geo-location - I hated its auto-redirection to the censored-for-Germany edition, I wanted the "international" (= US) edition. Maybe BE users are now in a similar position, trying to get an edition that's not censored-for-Belgium. Sometimes Geo-IP is cute, but it can be also a pain. > Even the choice of language subtag alone gets will > get complicated with 639-3. Yes, an ordinary select box with thousands of choices won't work, certainly not with my old browser. > With the UI selection for script, one could simply > have the default choice be "any" (meaning no language > tag), with a message that the script should not > normally be selected unless your language is customarily > written with multiple scripts. The registry offers Suppress-Script as indication when using a script could be necessary: For languages without Suppress-Script. > *real* guidance to the user would not use suppress > script -- instead it would give a choice, based on the > language subtag, of what the c ustomary values are. That info isn't in the registry. And if the application checks what CLDR says the implementor could offer Arab or Latn for tr. Resulting in tr-Latn. But the registry clearly says "don't do that, it's probably not what you want for tr". The Suppress-Script is a good feature of the registry. BTW, that's odd, we copied CLDR... Maybe it used to be only Latn, and Arab was added later. And of course the Suppress-Scripts and CLDR have different purposes. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 19:57:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTohE-0007xk-S3; Sat, 30 Sep 2006 19:56:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTohE-0007xf-5x for ltru@lists.ietf.org; Sat, 30 Sep 2006 19:56:40 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTohC-00088y-PT for ltru@lists.ietf.org; Sat, 30 Sep 2006 19:56:40 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GToh0-0003tY-PG for ltru@lists.ietf.org; Sun, 01 Oct 2006 01:56:26 +0200 Received: from pd9fba9b8.dip0.t-ipconnect.de ([217.251.169.184]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Oct 2006 01:56:26 +0200 Received: from nobody by pd9fba9b8.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Oct 2006 01:56:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 01 Oct 2006 01:55:42 +0200 Organization: Lines: 18 Message-ID: <451F03FE.200B@xyzzy.claranet.de> References: <200609302127.k8ULRpTL010013@nit.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba9b8.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] Re: RFC 4690 on Review and Recommendations for Internationalized Domain Names (IDNs) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org rfc-editor@rfc-editor.org wrote: > RFC 4690 > Title: Review and Recommendations for Internationalized > Domain Names (IDNs) > Author: J. Klensin, P. Faltstrom, > C. Karp, IAB > Status: Informational > Date: September 2006 [...] > I-D Tag: draft-iab-idn-nextsteps-06.txt > URL: http://www.rfc-editor.org/rfc/rfc4690.txt Pointer for info, it has references to RFCs 4645 and 4646. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 21:05:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTpm4-0000p3-FY; Sat, 30 Sep 2006 21:05:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTpm2-0000ox-RS for ltru@ietf.org; Sat, 30 Sep 2006 21:05:42 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTplz-0005wd-1t for ltru@ietf.org; Sat, 30 Sep 2006 21:05:42 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k9115PiG017020 for ; Sun, 1 Oct 2006 10:05:25 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5c0e_ebb15902_50e8_11db_8ba4_0014221f2a2d; Sun, 01 Oct 2006 10:05:25 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:53479) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 1 Oct 2006 10:05:18 +0900 Message-Id: <6.0.0.20.2.20060930180719.07033ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 30 Sep 2006 18:09:44 +0900 To: John Cowan , Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Suppress-script considered least harmful In-Reply-To: <20060929213924.GG28837@ccil.org> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <451ACCC5.6010609@yahoo-inc.com> <20060929213924.GG28837@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 06:39 06/09/30, John Cowan wrote: >I'm happy to keep Suppress-Script confined (as a matter of administrative >policy, not RFC 4646bis rule) to the languages of 639-1 and 639-2. As a technical contributor, I'd tend to disagree. There is no need to force people to be unnecessarily detailled when tagging. If it's widely accepted general practice that a language is written in a single script only, then just the language tag should do the job. Scripts, like regions, should only be added when they are really necessary. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 21:33:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTqCq-00035e-Be; Sat, 30 Sep 2006 21:33:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTqCp-00035Z-I1 for ltru@ietf.org; Sat, 30 Sep 2006 21:33:23 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTqCn-0002aW-02 for ltru@ietf.org; Sat, 30 Sep 2006 21:33:23 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061001013317.NHVW28964.mta10.adelphia.net@DGBP7M81>; Sat, 30 Sep 2006 21:33:17 -0400 Message-ID: <00a501c6e4f9$921001b0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <30b660a20609291802l359aed85wf8464c2a569ebfdf@mail.gmail.com> <30b660a20609301123r1253c808j3d3c61d447af26d4@mail.gmail.com> <007801c6e4c0$071e7c50$6401a8c0@DGBP7M81> <30b660a20609301218g5c7db7d8yb326fc2e0fbf4bd8@mail.gmail.com> <007f01c6e4c9$283ec6c0$6401a8c0@DGBP7M81> <30b660a20609301252o63b63296i797c54c98d95e20b@mail.gmail.com> Subject: Re: [Ltru] Re: Suppress-Script batch 1 Date: Sat, 30 Sep 2006 18:33:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Karen_Broome@spe.sony.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > We are arguing about angels on the head of a pin. I'm saying, it is > MORE informative to say > > Don't use script subtags when they are not necessary or inappropriate, > such as for non-written content. Such content may include spoken or > sung language. > > than it is to say. > > Don't use script subtags when they are not necessary. I'm fine with this, and in particular with the de-parenthesizing of the "spoken and sung" part. -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 22:13:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTqp0-0001HY-P8; Sat, 30 Sep 2006 22:12:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTqoz-0001H6-3z for ltru@ietf.org; Sat, 30 Sep 2006 22:12:49 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTqbB-0000vC-Bd for ltru@ietf.org; Sat, 30 Sep 2006 21:58:34 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061001015828.NYHL28964.mta10.adelphia.net@DGBP7M81> for ; Sat, 30 Sep 2006 21:58:28 -0400 Message-ID: <00ab01c6e4fd$16bc3610$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 30 Sep 2006 18:58:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ltru] Re: Ltru Digest, Vol 19, Issue 88 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > Let's not make up problems where they don't exist. I see no > groundswell, nor any realistic prospect of a groundswell, of people > tagging languages with unnecessary scripts. +1 to that. > Now, this is all getting away from Karen's quite reasonable desire to > provide people more clarity on the fact that for material that is only > non-written it isn't a good idea to include a script subtag. I could > even see, in some applications, tagging records with, for example, > zh-Zxxx, meaning unwritten Chinese. Then I could search records for zh > (meaning any zh, no matter whether spoken, or written in traditional, > or written in simplified, or written in pinyin), or filter that to > only non-written, or only simplified, or only romanized. Hold on, Zxxx is defined as "Code for unwritten languages." I don't see that as meaning the same as "linguistic content that is not written." Then again, I'm the literalist who argued for years that "sign language as used in the United States" wasn't the same as "American Sign Language." -- 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 Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 22:39:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTrEn-0003Et-Ba; Sat, 30 Sep 2006 22:39:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTrEl-0003Eo-UR for ltru@lists.ietf.org; Sat, 30 Sep 2006 22:39:27 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTrEh-0006Rs-IC for ltru@lists.ietf.org; Sat, 30 Sep 2006 22:39:27 -0400 Received: from terminus.local (c-24-6-153-109.hsd1.ca.comcast.net [24.6.153.109]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id k912e0jl004494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 30 Sep 2006 19:40:01 -0700 Received: from [127.0.0.1] by terminus.local (PGP Universal service); Sat, 30 Sep 2006 19:39:07 -0700 X-PGP-Universal: processed; by terminus.local on Sat, 30 Sep 2006 19:39:07 -0700 In-Reply-To: <451E9B3E.4CC@xyzzy.claranet.de> References: <00f901c6e399$643dc8f0$6401a8c0@DGBP7M81> <20060929193738.GD28837@ccil.org> <004f01c6e456$da197660$6401a8c0@DGBP7M81> <451E9B3E.4CC@xyzzy.claranet.de> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <32201CDC-44A7-4303-81C7-F3F4B93F773B@icann.org> From: David Conrad Subject: Re: [Ltru] Re: Submission: draft-ietf-ltru-4645bis-00 Date: Sat, 30 Sep 2006 19:39:05 -0700 To: Frank Ellermann X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org >> http://www.iana.org/numbers.html, which is no better. > I hope that IANA won't screw-up this link as long as > it exists. Me too. (:-)) Rgds, -drc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 30 23:08:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTrh5-0006DS-H9; Sat, 30 Sep 2006 23:08:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTrh3-0006DN-QY for ltru@ietf.org; Sat, 30 Sep 2006 23:08:41 -0400 Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound3-blu-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTrh0-0001HK-9r for ltru@ietf.org; Sat, 30 Sep 2006 23:08:41 -0400 Received: from outbound3-blu.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound3-blu-R.bigfish.com (Postfix) with ESMTP id 242C67B24C6; Sun, 1 Oct 2006 03:08:38 +0000 (UTC) Received: from mail1-blu-R.bigfish.com (unknown [10.1.252.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by outbound3-blu.bigfish.com (Postfix) with ESMTP id 0C800840087; Sun, 1 Oct 2006 03:08:38 +0000 (UTC) Received: from mail1-blu (localhost.localdomain [127.0.0.1]) by mail1-blu-R.bigfish.com (Postfix) with ESMTP id D73742384CF; Sun, 1 Oct 2006 03:08:37 +0000 (UTC) X-BigFish: VP Received: by mail1-blu (MessageSwitch) id 1159672117813487_13834; Sun, 1 Oct 2006 03:08:37 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail1-blu.bigfish.com (Postfix) with ESMTP id 68F93440058; Sun, 1 Oct 2006 03:08:37 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2006093020113457-1698774 ; Sat, 30 Sep 2006 20:11:34 -0700 In-Reply-To: <30b660a20609301249s39fbed9ew9e3454310f3c7d46@mail.gmail.com> To: "Mark Davis" Subject: Re: [Ltru] Re: Suppress-Script batch 1 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 From: Karen_Broome@spe.sony.com Message-ID: Date: Sat, 30 Sep 2006 20:07:24 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 09/30/2006 20:07:24, Serialize complete at 09/30/2006 20:07:24, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 09/30/2006 08:11:34 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 09/30/2006 08:11:37 PM, Serialize complete at 09/30/2006 08:11:37 PM X-Spam-Score: 0.5 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0006697597==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0006697597== Content-Type: multipart/alternative; boundary="=_alternative 001132D0882571FA_=" This is a multipart message in MIME format. --=_alternative 001132D0882571FA_= Content-Type: text/plain; charset="US-ASCII" "Mark Davis" wrote on 09/30/2006 12:49:55 PM: > > Let's not make up problems where they don't exist. I see no > groundswell, nor any realistic prospect of a groundswell, of people > tagging languages with unnecessary scripts. However, when it comes to tagging audiovisual content, I do see this quite frequently -- at least with Chinese language classification. (And I've analyzed audiovisual language data from many sources and studios.) The fault is not always an ill-informed classifier. Developers often advise against having separate or filtered language lists for spoken and written languages as they want to be able to do a basic query for all content in Mandarin or "Chinese" and don't quite understand the issue. "ISO doesn't make this distinction, why should we?" Or classifiers are stuck with a shrink-wrapped system architecture that assumes written content and a single language list. So when a classifier is faced with inappropriate choices for a dubbed or spoken work, they often choose a "scripted" form of Mandarin over suggesting a system redesign. It's not the role of the working group to design systems, but maybe giving this issue some attention might help developers who implement RFC 4646bis in systems that deal with both spoken and written language. Regards, Karen Broome Sony Pictures Entertainment --=_alternative 001132D0882571FA_= Content-Type: text/html; charset="US-ASCII"
"Mark Davis" <mark.davis@icu-project.org> wrote on 09/30/2006 12:49:55 PM:

>
> Let's not make up problems where they don't exist. I see no
> groundswell, nor any realistic prospect of a groundswell, of people
> tagging languages with unnecessary scripts.

However, when it comes to tagging audiovisual content, I do see this quite frequently -- at least with Chinese language classification. (And I've analyzed audiovisual language data from many sources and studios.) The fault is not always an ill-informed classifier. Developers often advise against having separate or filtered language lists for spoken and written languages as they want to be able to do a basic query for all content in Mandarin or "Chinese" and don't quite understand the issue. "ISO doesn't make this distinction, why should we?"

Or classifiers are stuck with a shrink-wrapped system architecture that assumes written content and a single language list. So when a classifier is faced with inappropriate choices for a dubbed or spoken work, they often choose a "scripted" form of Mandarin over suggesting a system redesign. It's not the role of the working group to design systems, but maybe giving this issue some attention might help developers who implement RFC 4646bis in systems that deal with both spoken and written language.

Regards,

Karen Broome
Sony Pictures Entertainment

--=_alternative 001132D0882571FA_=-- --===============0006697597== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0006697597==--